Wondershare EdrawMind
MindMap Gallery Succeeding With Agile-Software Development Using Scrum
- 218
- 4
- 2
Succeeding With Agile-Software Development Using Scrum
This mind map is about Succeeding With Agile: Software Development Using Scrum. Start to use a mind map to express and organize your ideas and knowledge right now.
Edited at 2020-09-29 08:24:29
- Wholesaling Blueprint - Steps to Wholesaling Real Estate Simple Systems
This mind map is about Wholesaling Blueprint - Steps to Wholesaling Real Estate + Simple Systems. Start to use a mind map to express and organize your ideas and knowledge right now.
- Western Front
This mind map is about Western Front. Start to use a mind map to express and organize your ideas and knowledge right now.
- THE SAMPLING PROCESS
This mind map is about THE SAMPLING PROCESS. Start to use a mind map to express and organize your ideas and knowledge right now.
Succeeding With Agile-Software Development Using Scrum
- Wholesaling Blueprint - Steps to Wholesaling Real Estate Simple Systems
This mind map is about Wholesaling Blueprint - Steps to Wholesaling Real Estate + Simple Systems. Start to use a mind map to express and organize your ideas and knowledge right now.
- Western Front
This mind map is about Western Front. Start to use a mind map to express and organize your ideas and knowledge right now.
- THE SAMPLING PROCESS
This mind map is about THE SAMPLING PROCESS. Start to use a mind map to express and organize your ideas and knowledge right now.
- Recommended to you
- Outline
Succeeding With Agile: Software Development Using Scrum
Outside Development Affects
Human Resources
Performance Reviews
Eliminate individual factors
how did the individual effectively managetasks within budget and timeline
Include teamwork factors
Helps the team finish tasks within the timeline
effectively applies retrospective items and helpsothers do the same
Review more frequently than anually
Career Paths
Scrum masters may rotate through differentteams of importance
Development team members may also rotatethrough different teams to share technicalknowledge
Role may also change on the team and initialtester/designer may rotate to biggerarchitectural inputs and implementation lateron in the team
Distributed Teams
Create Coherence
Acknowledge Significant Cultural Differences
Power Distance Index (PDI)
Individualism (IND)
Achievement Orientation (ACH)
Uncertainty Avoidance Index (UAI)
Long-Term Orientation (LTO)
Acknowledge the Small Cultural Differences
Strengthen Funcationl and Team Subcultures
Communicate and Establish a Shared Vision
Reach Agreements
Build trust by emphasizing early progress
Focus on tasks first
After learning about eachother with taskprogress and completion focus on relationshipbuilding
Get Together in person
Seeding Visits
Maybe even seeding the first sprint
Contact Visits
Focus around a task but the goal is relationshipbuilding
One week visit for every couple of months
Traveling Ambassadoors
Semi Permanent team member
Stays for several months
Rarely used this way so settle for shorter butmore often visits
Communicates Gossip
Not malicious rumors
Personal details that which aren't discussed informal meetings
'Fernando's baby took her first steps last night'
Communicate lessons learned
Change How You Communicate
User Stories
Supplement with some more detail
&Send a long a test&
Add a high level test case that indicates if thestory is complete
Encourage Lateral Conversion
Combats the 'mum' effect
Include time for small talk
Start telecons with chit chat
Encourages culture and a better mood for thecall
Telecons
Share the pain
Change meeting times monthly to make it fairamong team members
Have some meetings all by telecon, even thelocal members to show how difficult the phonecall can be to stay engaged
Tell Everyone who is talking
State your name before speaking
Have low-fidelity video conferencing
Have pictures with names and have someone hold it up when they recognize the personsvoice
Sprint Planning
The Long Phone Call
Two Calls
Scaling Scrum
Scaling the Product Owner
Keep a PO responsible for no more than 2teams
Scaled Roles
Chief Product Owner
Product Line Owners
Product Owners
Working w/ a Large Product Backlog
One Product, One Product Backlog
Keep to a Reasonable Size
100-150 responsible items
Robin Dunbar research
Use eipcs and themes
Use different views
Can have more than 150 but not in a singleresponsible view
Proactively Manage Dependencies
Do Rolling Lookahead Planning
At the end of Sprint Planning
Spend a few minutes discussing what each teamwill do in the next couple of sprints
Help identify dependencies early
Hold a Release Kickoff Meeting
Roughly plan 3 months out and discuss thosegoals with all teams so that everyone starts outon the same page
Share Team Members
Part time team members
Use an Integration Team
Best on projects with ten or more teams
First goal is to analyze nightly build and solveany nightly build problems with the teamsinvolved
Integration Team Member at every other teamsstandard meetings
Coordinate Work Among Teams
Scrum of Scrums Meeting
1 team member chosen by the team
if small # of teams perhaps 2 from each team
chosen members can rotate
Recursive; multiple levels of scrum of scrums
Frequency
Don't need to be daily
Dont need to be timeboxed to 15min
15 min may often be sufficient but block off 30-60m
Are problem-solving meetings
If the right people are in the meeting solve theproblem then and there
Agenda
What has my team done since we last met thatcould affect other teams?
What will my team do before we meet again thatcould affect other teams?
What problems is my team having with which itcould use help from other teams?
No personal names used during this part
As needed: Resolve problems and discuss itemson an issues backlog
Names can be used here to solve the problems
Synchronize Sprints
Staggering sprints are a horrible idea
Never a time when all teams are done
difficult to actually release the product
difficult to share team members or even just askothers for help
2 or 3 day stagger is acceptable on a largeproject
Allows members to attend multiple meetings
Remote members can attend all potentiallyuseful meetings
Scaling Sprint Planning
Stagger by a Day
Works for projects up to 9 teams
The Big Room
Big room with all teams split into their own'corners' and have normal individual sprintplanning meetings
Use nautical singaling flags for communication
Need architect
Need PO
Time to order Lunch
On a Break
Cultivate Communities of Practice
'Test Community', 'programming community''ScrumMaster community', 'UI Community'
Virtual Architecture Team (VAT)
Can span more than one project
Sprint
Keep Timeboxes
Teams benefit from a regular cadence
Sprint planning becomes easier
Release planning becomes easier
Never Extend
Discourages the commitment
Don't Plan on Overtime to Salvage a Plan
Leads to poor quality
Developers are forced to cut corners to meetpoor estimates
Work a Sustainable Pace
XP Rule:you can't work a second week ofovertime
If needed, the project has a big problem
The only acceptable overtime is team concludedand desired overtime
If a commitment has too much focus the teamwill not commit to what they can do but oftenmuch less to confidently commit
Add Energy vs Overtime
Increase the passion around the project
Pomodoro technique
5 min breaks to every 25 min of work
Favor Scope Changes
Alternatives
Cut Quality
Add Resources
Extend the Schedule
Shrinking scope is often acceptable to everyoneand can have huge benefits and keep a projectproductive
Product Backlog
Written Document Negatives
can make you suspend judgement
Leads to lack of conversation over meaning andoveruse of assumptions
decrease whole-team responsibility
Use User Stories
As a <type of user>, I want <some goal> so that <some reason>
Promise to have a future discussion; not everydetail required
Team should practice communication skillsw/ PO to speak about business not alltechnical
Add detail over time
Conditions of Satisfaction
Acceptance Criteria
Emergent Requirements are encouraged
Iceberg
Tip is known
Everything under water we know is there and itsa lot but its not very detailed, we will get to itlater
Grooming
10% of effort in each sprint
Why progressively refine
Things will change
Priorities shift
New needs are discovered or solved
There's no need
Items may be obsolete or unnecessesary as theproject progresses
Time is scarce
Allows decisions to be made at the optimal time
Allows to make course changes
avoid falling into trap of believing our plans
Should be 'DEEP'
Detailed Appropriately
Estimated
Emergent
Prioritized
Team
Two Pizza Team
Smaller Teams
Less social loafing
Constructive interaction
Less time spent coordinating
Higher Participation
More satisfying to the team
Less chance for harmful over-specialization
Productivity
Small teams are much more productive
Large teams complete projects on average 12days sooner than small teams
Costs a lot more money and has a lot moredefects
Favor Feature Teams
Feature Team Benefits
Better able to evaluate design decisions
Reduce waste
Ensures the right people are talking
Less risk to the schedule
Keeps focus on delivering features
Consider Component Teams ONLY if
Component team will build something that willbe used by multiple feature teams
Desire to reduce the sharing of specialists
Often feature teams run specialists thin theycan't really be utelized in code
Risk of multiple approaches outweighsdisadvantages of component teams
Multiple feature teams may need to solve thesame problems in a sprint and thats a big risk ofduplicated effort
You can see an end to the need for componentteams
Right People on the Team
Include all needed disciplines
Balance technical skill levels
Balance domain knowledge
Seek Diversity
Don't want teams that come to quick conclusions
Want teams that think through their conclusionsthoroughly
Consider Persistence
Try not to multitask teammembers
Total work decreases the more required tomultitask
Better to have a few members multitask a lot,than have the whole team multitask a little
Don't start a new project until it can be fullystaffed
Technical Practices
Test Driven Development (TDD)
Evidence it takes 15% longer
Initial bugs reduced by over 25%
long term bugs reduced ~ infinte
Try 'gang programming' for training
4-8 devs, 1 laptop, projector, pass thelaptop every 15m
Refactoring
Objections
If written/designed well wouldn't need it
like saying if cars were made better, wouldn'tneed an oil change
Opportunistic Refactoring
Always leave the code better off than you foundit
Collective Ownership
Ensure no dev becomes to specialized he cancontribute only in one area
Make certain that no area becomes so intricatethat it is understood only by one dev
Good ideas in one part of the application aremore quickly proagated to other areas
Objections
Development is faster if each person owns onepart of the system
in a very short term project probably
long term project not true at all
Continuous Integration
Nightly builds 100% essential
Continuous nearly a must have
no manual effort
Pair Programming
Objections
Costs two devs to do the job one one
Costs are deceiving
Lower defects and quicker to market outweighman hours cost
In a hurry, we can't pair
this is the most important time to pair then
You don't want to do the same job three times
Do the job once, right, you don't need to repeatit
Studies prove your faster to market when pairing
Two team members at a single computer activelyworking tasks
Can increase time to complete tasks by 10-15%
Number of bugs reduced by over 50%
Takes longer to do a task correctly thanincorrectly
Design: Intentional yet Emergent
Emerging design is more productive thanwaterfall design
Requires rework often
With sound technical practices like TDD, reworkis easy and fast
Rework leads to a best design to the projectwhile upfront design can't successfully changewithout rework
Quality/Testing
Why testing at the end doesn't work
It is hard to improve the quality of an existingproduct
Mistakes continue unnoticed
State of the project is difficult to gauge
Feedback opportunities are lost
Testing is more likely to be cut
Test Automation Pyramid
UI
Brittle
Expensive to Write
Time Consuming
Service
Unit
Roles
Scrum Master
Personal Trainer Analogy
They have the authority to keep you on the righttrack with the right exercises
Ultimately has no authority over you. Youmake your own decisions on what to do
Keep team focused on goal
&we're supposed to deliver potentially shipablesoftware. What do we need to do next time toget that?&
CAN'T tell the team what to do
Not &Tod reviews all code from now on&
Therefore is not responsible if the team fails
But should help them have the conversations to get them back on track
Attributes of Good Scrum Master
Responsible
Humble
Collaborative
Needs to create a collaborative environmentfor the team
Almost like a good teacher
Be willing to do what is necessary to open theteam up and communicate effectively
Committed
Influential
Clever and effective influence to get a team totry new things
Not a 'because I say so' style
Influence others outside the team to helpovercome roadblocks
Knowledgeabble
Tech leads != Scrum Master
teams should not have tech leads
tech leads often make better team members
Scrum Master does not have authority of theteam so don't try to keep that authority bybecoming the scrum master
&my way or the highway& leads are bad ScrumMaster candidates
Product Owner
Responsibilities
Providing Vision
Providing Boundaries
Need x by June
Needs to run at twice the speed
Focused on Return on Investment (ROI)
Represents the interests of the stakeholders
Each team needs exactly one product owner
Team of Product Owners for larger projects
Needs to be one person per team, not acommitte
If a PO team members feels uncomfortableanswering, there has to exist a PO lead tomake the decision, not a committe
Attributes of Good Product Owner
Available
Business-savvy
Communicative
Decisive
Empowered
Team Member / Programmer
'OK' to have specialists, best to have the teamwork across the board
Need to become active participants in productrequirements
No longer being told what to do, need tounderstand what needs to be done
Overcoming Resistance
Skeptics
Provide training
Solicit peer anecdotes
Appoint champion skeptic
Acknowledge the skeptic and go to him foralternate views to further conversation andtackle issues
Push the issue
Challenge the skeptic to come up with iterativesteps to solving the skeptic outlook
Let time run its course
Saboteur
Success
Prove success on diverse projects
Reiterate and reinforce the commitment
Move them
To a different project
To a different type of role
bye bye
Fire them
bye bye
Diehards
Align incentives
They are diehards for a reason use that
Create dissatisfaction with the status quo
Acknowledge and confront fear
Followers
Change the composition of the team
Praise the right behavior
Involve them
Identify the true barrier
Pilot Project
Pilot != to decide to do it
Pilot = forge the way to understand thebest approaches at the company
Picking best pilot project
Duration
Whatever is near the 'middle' of what is normal
Ideally ~3-4 months
Size
Single Collcoated Team
It may grow over time
Keep growth under 5 teams
Importance
Choose an important project
Gives it best chance to over come roadblocksand not be called a unique/special case
Business sponsor engagement
A good sponsor can help overcomeexternal roadblocks
Can champion the successes across thecompany
Manage Expectations
Most teams will over commit
Most teams will be more useful
Poor teams will get good fast
Good teams may slow down at first, and begreat in the end
Initial predictability will be poor
Estimates will start out poor
Teams take a few sprints to find a sustainablepace
Level of involvement
PO and stakeholders have significant roles forthe team to be successful. Don't underplaytheir need.
Iterate Toward Agility
Use Scrum to Apply/Adopt Scrum
Improvement(Product) Backlog
Example Items
Enable teams to implement CI
Create Awareness of Scrum on each Team
Figure out how to make sure each team has aPO
Multiple backlogs for large companies
Enterprise Transition Community (ETC) (TheTeam)
Daily Scrums encouraged, not as important asdevelopment scrum teams
Responsiibilities
Articulate the context
Stimulate Conversation
Provide resources
Set appropriate aspirations
Engage everyone
Sponsor (PO)
Probably an experienced PO, this is new
Doesn't have to be the sole PO, the ETC canhelp heavily
Does need to be committed and apply time
Needs to be senior management/partner/cofounder to help adoption
Form Improvement Communities
Like sub ETC teams where the/an ETC memberis the PO
Spreading Scrum
Split and Seed
Split a team after a few sprints into two teams,mixing the new teams with 'other' (new orotherwise) team members
Can add teams quickly
But destroys teams just starting to jell
Grow and Split
Grow a team into a large team, and then splitthe team into two teams.
Continue to grow those teams and split again
Keeps teams together (mostly)
Most natural
This would happen as projects grow
Internal Coaching
Successful team member helps another teamwhile continuing to work on the original team
Keeps teams together entirely
Coaches can be hand selected
Can move from one team to another
Attends:
Sprint Planning
Review
Retrospective
1 Daily Scrum a Week
2 hours a week for other help
Becoming Agile is Hard
Why Transition is Hard
Successful change is not entirely top-down orbottom-up
The end state is unpredicatable
Scrum is pervasive
Scrum is dramatically different
Emergent Design vs Waterfall
Change is coming more quickly than ever before
Best practices are dangerous
Each business has different needs, thusdifferent practices
Cannot plan every project with a rule book orbest practices
Why it's worth the effort
Higher Productivity and lower costs
Improved employee engagement and jobsatisfaction
Faster time to market
Could go to market after every sprint if desired
Higher quality
Improved stakeholder satisfaction
What we've been doing no longer works
Leading a Self Organizing Team
Containers
Change containers
How does the team make decesions, change it
Phyiscal space of the team
Differences
Ensure teams are diverse amplify differences
Exchanges
Change how an exchange occurs
Add or remove people from exchange
Different meetings between different people
Influencing Evolution
Select the External Environment
Define Performance
Manage Meaning
Energize the System
Give clear and elevating goals
Crerate Project Charter
Write product review and eleveator statement