This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• Italian musical espression: fast, trills, embellishments • Project Management: the flexible and fast response of organizations to unpredictable changes and customer demands
Ability Static Can Grow Goal To look good To learn Challenge Avoid Embrace Failure Defines your identity Provides information Effort For those without talent Path to mastery Misfortune Helplessness Resilience
• Extreme Programming (XP) • Crystal Family • Dynamic Systems Development Method (DSDM Atern) • Test-driven Development (TDD) • Essential Unified Process • Agile Unified Process • Scrum • Kanban
AGILE The Agile Family
Incremental Delivery: don’t bite off more than you can chew
Source: Steven Covey - The Habits of Highly Successfull People
Agile Manager: Servant Leadership
• Shared Vision Distilling the customer’s grand vision into a meaningful plan for everyone involved in the project Layout a common set of understandings from which emergence, adaptation and collaboration can occur
• Environment Enhancing team productivity by doing whatever possible to minimize obstacles and optimization of the environment Battling organizational dysfunctionality
• Politics Using the various agile mechanisms to minimize politics and keep everything visible and obvious
• Continuous Improvement Promotion of an organizational culture of continuous learning (from mistakes)
• is a empirical process framework for developing and maintaining complex products • delivers products of the highest possible business value • is simple to understand, but very challenging to master • has a history of success on a wide variety of projects • makes clear the relative efficacy of product management and development practices • will surface (organizational) issues quickly, offering possibilities for significant improvement • is not a silver bullet
Problem with IEEE-830 style software requirements: • Tedious to read, so readers skim or skip sections • Multi-interpretable, error-prone • Assumes everything is knowable in advance
If detailed requirements are written down
The user will get what he/she wants
At best, the user will get what was written
then
You built what I asked for, but it’s not what I need
Requirements Specification the formal way
1. The product shall have a gas engine
2. The product shall have four wheels
2.1 The product shall have a rubber tire mounted to each wheel
• User stories bring the customer perspective into the project, providing a concise ‘hook’ for business goals and user expectations
• User stories are a medium for discussion and prioritization of requirements with (non-technical) stakeholders
• User stories promote participatory design and supports cross-functionality in the team
• User stories will make clear what the users actually need (instead of what they want)
• User stories facilitate realistic project
monitoring and reliable release planning
ID 13 11
5
16
User Stories As a GIS administrator I want to restrict editing of the State Forest Layer to only users in the Editor's role so that this layer isn't accidently edited As an Editor I want features in the State Forest Layer to be automatically clipped by the Forest District Features so that correct topology relationships are maintained As a GIS administrator I want the system to block standard deletions from the State Forest Layer, so that Users am forced to formally dispose of the feature As an Editor I want features in the State Forest to be automatically checked so that no features overlap within the same layer
User Stories As a GIS administrator I want to restrict editing of the State Forest Layer to only users in the Editor's role so that this layer isn't accidently edited As an Editor I want features in the State Forest Layer to be automatically clipped by the Forest District Features so that correct topology relationships are maintained As a GIS administrator I want the system to block standard deletions from the State Forest Layer, so that Users am forced to formally dispose of the feature As an Editor I want features in the State Forest to be automatically checked so that no features overlap within the same layer
Project Backlog: Landscape Exam Tool
Sample Product Backlog
Estimation (Story Points)
5 8 4 3
Have conditions of satisfaction which can
be tested at review/delivery
Are product features described within the context
of the customer/end-user
Have no or minimal dependency on other user stories
May contain a reference to detailed specifications
Fits into a single sprint to keep the work flowing
Sometimes the scope and content of user stories or epics can be understood
only after targeted analysis
A spike is a special type of story for activities such as:
exploration, research, analysis, design, proof of concept, prototyping, etc.
Gain knowledge necessary to:
• Underline architectural trade-off decisions • Reduce risk of a certain technical approach • Better understanding of critical requirements • Increase reliability of high-level estimations • Disaggregate large user stories into constituent stories
Epic: As a consumer, I want to see my daily energy use in a histogram so that I can quickly understand my past, current and projected energy consumption
Technical Spike: Research how long it takes to update a customer display to current usage, determining communication requirements, bandwidth, and whether to push or pull the data. Functional Spike: Prototype a histogram in the web portal and get some user feedback on presentation size, style and charting
The Product Backlog: shields the team from interference
• The financial value of having the feature • The cost of developing / supporting the new feature • The amount and significance of learning and new knowledge created by developing the feature • The amount of risk removed by developing the feature • The business impact of not (yet) having the feature • …
Guidelines for prioritizing user stories or epics:
Focus on team’s environment • setting up computers • creating team room • development environment • tooling • … Preparation for first sprint • make high-level architecture overview • produce project charter • gather all relevant features • produce first version of product backlog • define ‘minimal viable product’ • agree on default definition of done • …
Release Sprint Hardening Sprint:
• Performing time-consuming regression testing • Deploying the code from the Sandbox to Production Environment • Production data population • Setting up operational systems and processes • Training and handover for support staff
• Product Owner presents updated Product Backlog • Product Owner describes features to be realized • Product Owner indicates associated priorities • Development Team presents total number of available hours for the next sprint • Scrum Team agrees upon the Sprint Goal
WHAT - What is the goal of the next sprint?
Sprint Planning Meeting
• Product Owner clarifies Product Backlog items if needed • Team decides how to build the selected functionality into a product increment • Team breaks Product Backlog items (features) into tasks • Team may invite other people to provide technical or domain advice • Team presents a concise plan for realizing the Sprint Goal: the Sprint Backlog
HOW - How will the chosen work get done?
88
Estimation of Productive Time
Team member A: 40 hours Team member B: 20 hours Team member C: 30 hours Team member D: 10 hours Available: 100 hours
Rule of thumb: 6 effective hours per 8-hour working day No contingency planning!
Burn down charts promote: • Transparancy: visibility of time spent on not-agreed upon work • Alignment: absence of last-minute surprises • Adaptivity: facilitate timely corrective actions • Co-Creation: tracking is at the team-level, no blame-game
part of the ‘definition of done’ of selected tasks.
Requested Quality: Part of the ‘Definition of Done’
‘Better than requested’
is the enemy of ‘Done’
“What is Working Software?” – www.improvement-services.nl/blog/?p=344
Agile Testing towards an integrated test process
• Testing is not a distinct phase Testing should be a continuous activity of any Agile team Testing activities are integrated with the development process
• Testing is not an exclusive activity All team members must be prepared to perform test activities Testing is not the sole responsibility of the designated tester
• Testing when possible Early testing, starting in phases of gathering requirements and design, is highly recommended. • Test tools are indispensible
Advanced test tools and test automation are needed
• Testing is part of the ‘definition of done’ A release or iteration is done when it is fully tested, test results are processed, and problems are resolved
Examples: “[We use Scrum, but] [having a Daily Scrum every day is too much overhead,] [so we only have one per week.]" “[We use Scrum, but] [Retrospectives are a waste of time,] [so we don't do them.]" “[We use Scrum, but] [we can't build a piece of functionality in a month,] [so our Sprints are 6 weeks long.]" “[We use Scrum, but] [sometimes our managers give us special tasks,] [so we don't always have time to meet our definition of done]"
• Company management is not committed or works against Agile principles no understanding of Agile and Scrum matrix numerous people into numerous projects fixed time, fixed scope and fixed budget projects
• Product Owner there is not product owner at all product owner is not available product owner has no mandate of the organization product owner has no access to real users or stakeholders user stories not available or not suitable/ready for implementation
• Development Team team composition changes all the time no cross-functionality possible due to missing expertise daily interference and context switching massive stream of unplanned work no project focus: most team members are not dedicated
• Product full predictability/no innovation: all requirements are known upfront work cannot be divided into smaller chunks
Kanban: work-flow optimalization • Visualization of the Work-Flow • Limitation of the Work in Progress (WIP) • Measurement of the Lead Time of Work-Items • Identification of Bottlenecks in the Process
Which contract forms are best for agile software development projects
and at the same time commercially competitive?
Variable Scope • Customers can change their minds • Suppliers aren't encouraged to sacrifice quality • Customer's and Supplier's interests are aligned Incorporate customer
responsibility
Agile Contracting: Evolutionary delivery in close co-operation with the customer
Customers have what they want at the project end, after they've learned,
instead of getting what they wanted at the project start.
Much work remains to be done before we can announce our failure to make progress
Traditional Planning A Joyless Track Record
• Planning is by activity rather than feature - Parkinson's Law
• Lateness is passed down the schedule - Pattern: Anti-gravity Module
• Multitasking causes further delays - assigning work to individuals rather than to groups - focus on high level of utilization of all individuals
• Features are not developed by priority - dropped features may be of greater value than those that are delivered
• Uncertainty is not acknowledged - product specifications are generally imperfect or incomplete - assignment of precise estimates to imprecise work - estimates become commitments (or even deadlines)
Work expands so as to fill the time available for its completion.
Between 1935 and 1954 the staff of the Colonial office increased from 372 to 1661, over 400% - while the responsibility of the Colonial Office was declining. By the time of the end of the British Empire, the Department had its highest number of staff ever.
Colonial Office, London
Activity Planning A common pitfall
A critical problem with traditional planning is that they focus on the completion of activities
rather than on the delivery of features.
Activity-based planning doesn’t guarantee that customers get value from the completion of activities.
Features are the unit of customer value.
Planning should be at the level of features, not activities.
Germany Denmark Estland United Kingdom Belgium Spain Poland Netherlands Cyprus Finland
Country Inhabitants XL
L
M
S
XS
M
• Forces the use of relative estimating studies have shown that we're better at relative estimating (over one order of magnitude) rather than absolute estimating
• Focuses us on the size, not the duration story points are independent of the time needed for realization, therefore, estimating in story points is typically faster
• Puts estimates in units we can add together time-based estimates are in most cases not additive, (and may require obscure correction factors)
Why Story Points?
Story Points are a more usefull measure for project velocity and release schedule
1 As selling car owner, I need to clean and wax my car in order to get a good price for it.
2 As a car owner, I want to have the interior of my car completely cleaned, in order to travel comfortably.
3 As a car owner, I have to purchase and tryout a set of snow-chains, in order to be safe when on winter holiday.
4 As a car owner, I need to replace the headlight bulb, since the dimmed light is not functioning anymore.
5 As a car seller, I want to make an 2-page advertisement for all the second-hand cars in my shop, to attract new customers.
6 As a lover of classic cars, I want to renovate the metalwork of my 1952 Citroen Traction Avant, since the body is rusty.
• Combining individual estimates through group discussion leads to better overall estimates • Emphasizes relative estimating, hence we don’t waste time in meaningless arguments • Everyone's opinion is heard, thereby minimizing estimation bias and anchoring
• It's quick and fun
see www.planningpoker.com for planning poker for distributed teams
Project Budget: Forecasted Lead time: 20 weeks for realization of 500 Story Points Estimated Overall Cost: 20 x 5 FTE à $ 600/week = $ 60.000 Average Cost per Story Point: $ 60.000/500 = circa $ 120
Start of project
Product Backlog Size = 500 Story Points
member 1 member 2 member 3 member 4 member 5 Member 6