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 for Mobile
Transcript of Agile for Mobile
Staffing the team
Role of stakeholders
Preparing for sprint planning
Sprint review and retrospective
handover to the customer
feed back from customer demo
A Sopra Company
Scrum : between myth and reality
How to improve predictability
Creating the project charter
Business Objectives and Orientations
Directions concerning the solution
In scope and out-of-scope items
Identities of the main stakeholders
High level budget and governance
Staffing the team
1 Scrum Master
Developers (by domain)
1 Applicative (back-end)
1 solution architect
It's really important that we clarify everyone's role.
It's also important that we identify support required from people that are not part of the project team.
Role of stakeholders
Stakeholders provide information to the Product Owner about features and work the Scrum Team needs to do.
They also regularly review deliverables and discuss them with the Product Owner to confirm the work the Scrum Team will need to do.
Finally, they need to work with the Scrum Team during the entire release.
It's important to protect the
team from bad communication
the team has to focus on its committements
It's important we select the communication
we do about the team : to manage conflicts
internally and only escalate when needed
It's important to keep the team informed
about the steering committee's
Well communicate about the roles
The power of retrospective
Never skip the retrospective
All team members have to talk and feel free to talk
This might make you aware about hidden issues
It empowers the team
To synthesize the issues, decide about actions and to progress on them
Try to identify the prework needed
for a story to be delivered and try to work on it one iteration before:
infrastructure, business question, development
If this work involves the team effort, it has to have story points so that the velocity is well calculated
To split the stories in a really small and shippable ones
The testing has to start at the very
beginning of the delivery
Act as a team
An agile team is composed by
people coming from different BUs or different countries. They need to avoid silos and act really as a team
Some tips to strengthen the team identity:
To give a name to the team, a mailing list with only team members, to sit in the same place
when possible, and to do the scrum in the same room.
Build some kind of ritual and identity
Technology and skills
Promote non functional stories especially: test automation and continuous integration help teams complete user stories within a sprint
You can include these stories in the Product Backlog with a certain number of points assigned to each Sprint. This gives clear visibility and awareness of the efforts the team makes
It's important that we have at least a backup for every skill in the team
Starting a scrum
Decide about communication Tools
Never do sprint planning on a Monday morning. The team is not yet at its best and it is the most common day for holidays and sickness
Never hold reviews or retrospectives on a Friday afternoon.
The team is tired and thinking about the weekend. Therefore choose sprint boundaries on Tuesdays to Thursdays
The Agile Manifesto says developers and business people must work together daily and that face-to-face conversation is the best way to transfer information.
For a collocated team, ideally the team members have to share the same workspace. They can have a story board corner on which they manage stories by post it.
For a distributed team you need to share a tool on which you can visualize the story board.
The one we use in HR Access is Atlassian suite.
The team can make the scrum calls via phones.
We can also use the chat tool in parallel.
Prepare for sprint planning
Preparing the backlog
Prepare and prioritize the backlog
Challenges for distributed teams
Communicating with distributed team members
Time Zones and Working Hours
Language differences : keeping language simple
Giving everyone a chance to speak
The team has to decide about the iteration length
For mobile it was 3 weeks
We can sometimes choose to change the iteration's length for some constraints (i.e. to fit with a delivery date, vacation, etc.).
Each iteration starts with an iteration planning (or poker meeting) and finishes with an iteration review and a retrospective.
During the iteration we do scrum calls every day.
We can also manage some preplanning sessions for the coming iteration during the ongoing one.
Sprint review and retrospective
Post development activities
One of the major principle of Scrum is that team members responsible for delivering the work should estimate it.
During the 3 to 5 first iterations, we try to identify the velocity of the team.
On further iterations we try to stabilize it.
We size the stories:
We use stories points (0, 1, 2, 5, 10 or 20)
Stories higher than 20 points have to be split
According to the size, try to estimate how many stories we can deliver during an iteration.
Ideally the staffing has not to be reduced to keep the same velocity.
It's important that we size even technical requirements to reflect all the effort produced by the team.
The Product Backlog includes everything needed to launch a product, as follows:
• Work items to address the features of the product
• Development requirements, such as setting up systems to begin development
• Exploratory work items to help with technical decision-making for developing the product
• Fixes for known bugs
The product backlog can evolve during the iterations.
We give higher priorities to items with a higher business value.
The preparation for sprint planning can take place during the previous iteration: we can also call this design meeting.
The aim is to come up with a high-level design to understand the difficulties and dependencies before the team does the sprint planning itself.
Commonly architects, business analysts are also invited.
The Product Owner should have a prioritized list of requirements (user stories) in the Product Backlog that will be used by the team.
All the team members must work together to commit to how much work they can complete, what work will they complete, and how will they work together to complete.
The First Half of Sprint Planning: Deciding what to do.
The Second Half of Sprint Planning: Deciding How to get the work done.
The sprint planning
The Scrum team gets together for 15-30 minutes and each team member responds to three simple questions
• What did you do yesterday?
• What are you going to do today?
• Do you have any blockers?
The aim is not to do micromanagement, but to communicate and coordinate the team efforts and possibly revise their daily plans based on the answers of the others.
We use the phone during our scrum.
It's important we make sure every body understands.
We sometime process the scrum by focusing on stories rather than people. But at the end, everybody has to talk.
During the Sprint Review we assess whether the Scrum Team achieved the Sprint Goal. The PO, the scrum master and the scrum team take part of the meeting.
We don't necessary invite stakeholders
neither do a demo since the PO validates a story as soon as it's closed.
The sprint retrospective takes place after the sprint review to analyze or assess how well they performed, to identify issues or things to be improved.
Some identified issues are to be reported to stakeholders for action.
How to be more predictable