Why Agile? Well...
At a certain point all of us may agree with this image.
What we will be having fun with during the next hours.
Agile vs Classic Product Development
Agile Values and Basic Principles
Scrum Roles and Process
Basics of Agile Product Development
Classic product development
What about teamwork?
Watterfall can be compared to a relay race
Seems to me that this approach does not promote a complete team environment.
What about considering a cooperative approach?
Core idea of agile software development is a continuous (incremental) development of the product while continuously considering customer feedback.
Individuals and interactions over processes and tools.
Working software 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."
Agile Principles I
1. Highest priority is to satisfy the customer with early and continuous deilvery of valuable software.
2. Welcome changes even in late development.
3. Deliver working software frequently, from a couple of weeks to a couple of months.
4. Business people and developers must work together daily throughout the project.
Agile Principles II
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development and keep a constant pace indefinitely.
Agile Principles III
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity--the art of maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Scrum is a Rugby formation - players stand closely in touch with each other.
- Focus on Team
- Joint discussion of the next move
- Self organization
Scrum is a Proccess-Framework.
- Easy to understand
- Hard to master
Product Owner (PO)
The PO is owner of the product and steers the development of the product from the functional point of view. He maximizes the product value by maximizing the outcome of the development team work.
- Bundle knowledge about the product and its environment.
- Maintain the product backlog by creating and sorting product backlog items (PBIs).
- Provides the developers enough information about the product and the PBIs, so they can implement them.
PO and the Value Curve
In simple terms, PO is the person in charge to determine what brings more value to the product faster.
The Developers steer the development of the product from a technical point of view. Main goal is to transfer PBIs into increments.
- Size: 3-9 (why?)
- Self organizing
- No hierarchies, no sub roles
The Scrum Master is responsible that Scrum is understood and enacted. He is consultant for Scrum itself. For doing so, monitors the way the team works and supports it if desired.
The more unexpererienced the team is, the more important is to have a Scrum master. For experienced teams and companies the scrum master might be omitted.
- Ask the team!
- Make himself unemployed.
- Coomunication of Scrum Values in his company.
Kind of a Micro-Project, a container for all event and the heart of Scrum.
If the team decides for a short duration there will be space for more inspections and adaption, however in side effect there will be less space for development.
At the other hand with longer Sprints where will be less inspection but more time available for development.
An Sprint must only be cancelled in a really exceptional case, and only by the PO!
Planning is the cerimony where the PO and Devs decide what can be done during the Sprint. Eight hours or less is the recommended duration for sprint with four weeks.
- Product Backlog
- Increment from that last Sprint
- Developer team capacity
- Written Sprint Goal
- Sprint Baclog
The method commonly used to estimate PBIs is called Planning Poker.
The unit used to measure the size of a PBI is called Story Point, it does not represent time, the value just tells us how big the PBIs is. For example instead of a number it is possible to use T-Shirt sizes to measure, XS, S, M, L, XL and so on.
When estimating an PBIs each member of the dev team analyses separately the PBI and chooses one card from the possible ones. The smaller the number the easy is to have that PBI completed, for example a PBI with a 3 story points is way smaller than a PBI with a 40 story points.
An everyday exchange between all developers about the current activities of each team member. The duration is equals or equals fifteen minutes for a team with nine team members. It must happen at the same place and same time.
These questions should be answered by each team member
- What I have done since yesterday (since the last daily)?
- What I will do today ( until the next daily)?
- Are there blockers / impediments?
Bigger topics should be moved to an offline discussion in order to keep the timebox.
The whole Scrum-Team takes part on the Sprint-Review, organized by the PO or Scrum Master, including the stakeholders (users, partners, leadership, members, etc.)
- Demonstrate the results of the recent sprint (inspection).
- Agree on next steps to increase the product value(adaptation).
Closed meeting for developers at the end of each sprint with an duration of three hours for a four weeks Sprint.
- Investigate the recent sprint.
- Identify potential improvements.
- Create concrete plans for improvements to realized during the next sprint.
A non official Scrum cerimony, that aims to keep the team involved to search for new ways of doing things. Usually happens between the Retrospective and the Sprint Planning
During the slack develoepers can work on any tech stack that they want, study or do whatever they want that can contribute to the development of team skills. This was created to keep a maintainable environment.
The absence of pressure during this time sets free the creativity and cool stuff may arise. Usually after a couple of slacks a developer present to the others what he is working on.
After the execution of a couple of Sprints it is possible determine the velocity of the team.
It isn't as precise as you may want however looking for Sprints that were completed it is a good way to predict how much work can be done.
Containers for results produced by the Scrum Team.
A simple list of everything which can be introduced in the product during the following Sprints, ordered by priority. Only the PO can add or remove items or change priorities.
Backlog in Jira
Product Backlog Item (PBI)
Each PBI must have a description, priority, estimation (estimated by the dev team during the planning).
The PO refine and enriches PBI iteratively changing them as more is learned (product, market, technologies).
A meeting for refinement on PBIs can be done with help of stakeholders and developers, this is usually called Backlog Grooming and it is not part of official Scrum.
Level of details for PBIs
The level of detail must be reduced for PBIs that are going to be implemented later. The less the value of a PBI(from the current point in time), the less the level of detail.
Definition of Done (DoD)
The DoD serves as a checklist. It can be only set to done when all criteria of the DoD are satisfied.
Its a list created by the developers and communicated to the PO. It can be continuously improved during the sprints.
- Strenghtens trust relationship between PO and Developers.
- Facilitates a common understanding of the Developers when a task is done.
A list containning all the PBIs that will be developed in the current Sprint.
It belongs to the developers and serve as a central point of what needs to be done and a transparent indicator to the whole Scrum-Team.
The increment is what is usually known as the Product.
Potentially shippable after each sprint.
When working in projects that has a 'defined' scope, group the team and identify all the user stories at the beginning.
After defining what is possible to be done in the future, estimate them. This will be difficult but necessary, since stakeholders will be asking for progress. These estimations will change in future but a starting point is necessary.
Developers tend to avoid this premature estimation because they thought that this will be used against them in future, however this is not the point in Scrum at all.
Basics of Agile
Automation and standardization
Agile simply does not work without testing. They must be implemented and automatized by the developer
Who never did that, huh?
Show tools and current status of projects.
Thanks for your attention.
Standing on the shoulder of giants.