Agile Software Development: Progress adn Impact Flashcards
What are Agile Assessments?
In agile, to measure progress and impact we capture and look at metrics but, we also focus on how people are interacting to determine what is impacting the program or project. It is important to take cues from your team, know where you are, know where you want to go and make the necessary changes to ensure you get there.
One simple way to go about doing this is to conduct an agile assessment that will help you and the team determine where to improve first.
If we want to know how agile a project is, what should we look at?
Which kind of metrics are being tracked
Traditional:
Integrated Master Schedule(IMS)
Earned Value
person-hours, etc
Agile: Burndown charts Burn-up charts Story points Committed VS delivered Value delivered Lead time Cycle time
IMS - Integrated Master Schedule VS Product RoadMap
IMS tries to predict the future and assumes we know everything there is to know upfront
Roadmap instead focuses on what is important to the customer NOW now and does not try to predict the future
Earned Value VS Value Delivered
Earned Value assumes that spending money equates to value, but money spent does not always result in value.
Burn Up/Down charts focus on the Actual Value Delivered to the client. Work is either done or not done
True or False:
Using an Integrated Master Schedule is far more accurate than using a Roadmap.
While an Integrated Master Schedule (IMS) can be used to plan individual projects with great precision, Agile projects allow for customer feedback to adjust the plan often and early. A Roadmap, therefore, can better help Agile teams guide and direct our work.
Looking at a burndown chart, how can you tell when a team is falling behind?
Above the ideal line
Continuous Improvement
Code Reviews
Coding Standards
Automated Testing
Retrospectives
Sustainable Development
The abillity to maintain a constant pace indefinetely
Regualr 40 hour work week
No working all night to finish a project
time off after heroic efforts
Your team is a resource - don’t burn them out
Why do you want to pace to be sustainable?
A sustainable pace ensure delivery is stable and predictable after 5 sprints
Code Reviews
Code reviews: formal reviews of code by your peers in which you discuss how and why you solved a technical problem and show others how it was done to help spread knowledge across the team.
What rate of improvement would be adequate after 3 - 5 sprints?
Max of 10% velocity improvement per sprint, but this will end at a certain time when the team matures
Sprint Retrospective
3 hours or less
Immediately after the sprint
Team members and Scrum master. Attendance by Product Owner is Optional
3 quesitons
What went well?
What didn’t go well?
What can be improved?
Why would you not want the PO to attend the Retrospective?
To allow the team to express their opinion about how the PO is impacting team performance freely
What is the output from the retrospective?
Lessons captured, which when put into practice becomes lessons learned
feedback placed in the backlog for PO to review and prioritize (tune and adjust)
What is the ultimate goal of retrospectives?
to tune and adjust performance in order to reach a state of sustainable development
How to turn lessons captured into lessons learned
Look for items that can be actionable, place them as User Stories in the Backlog, and have the Product Owner prioritize the Stories for work.
information radiators
Information Radiator: the term for any 1-2 charts or displays which a team places in a highly visible location so that all team members, as well as passers-by, can see the latest progress and information at a glance. Information radiators are used to help “radiate” information, and a Kanban board is an example of an information radiator.
BVIR
Big Visual Information Radiators
Good rules for an Information Radiator
Should be available on-demand, should not have to be generated
Should be highly visible, open to anyone to review, even the janitor (depending on security needs)
Should have live information that is up to date
Should be visual
Could be digital, paper, or whiteboard
the information included in a BVIR
Team Name The vision of the project Roadmap of the value delivered User Stories completed in the most recent iteration or sprint Burn Down Charts Burn up Charts Estimates for completion Actuals for completed projects
Minimum info that should be included in a BVIR
Team name Vision Roadmap Burn Down Burn Up Estimated Completion Date
Main Question answered by burndown chart
Is the team performing as expected?
Main Question answered by the burn-up chart
What work has been completed
Main Question answered by velocity chart
How much work is being completed each sprint
The main question answered by the committed vs delivered chart
Is the Team committing to and delivering work as expected
Velocity increases as the team get better at:
Estimating
Working together
Completing work items
Why is it important to recognize peak performance?
Because teams have a maximum work capacity and pushing a team harder when they are already performing at their peak will have negative outcomes
warning signs to look out for in charts
Teams increasing every sprint, especially after 6 sprints
More than 10% increase per sprint
“Cooking the books” - increasing the story points while doing the same amount of work
Patterns for continuous improvement
Retrospectives with takeaways:
- takeaways are items that specific people will work on
- Can include work placed in the backlog
- Ensure that the lessons learned are applied in future sprints
Gradual improvements that peak:
- improvements of 10% or less
- Not over-working and over-committing resources
- Sustaining peak performance
Being Agile
- Team completes all work without handing it off to another team to complete
- Updates documentation as work is finished
- Completes testing to ensure no bugs are passed along
Anti-Patterns that inhibit Continuous Improvement
Doing Agile, not being Agile
- passing work to another team, like passing work done to a testing team or integration team
- Sprints that last too long
- Management permission needed for minor changes
- No product demos for end-users
Combining Waterfall and Agile
- Agile and waterfall are mutually exclusive
- Agile is about adjusting based on customer feedback
- Waterfall is about following a plan
Falling back into old habits -Focussing too much on documentation -Change approvals -teams passing work to other teams -
Earned Value
a traditional project management tool used to travel money spent and work as it progresses. In Agile we DO NOT state there is any value until the software is delivered. 99% done in Agile is not-done, period
Man-hours
a way to track how much work hours have been spent to date
