Succeeding With Agile: Software Development Using Scrum

Get Started. It's Free
or sign up with your email address
Succeeding With Agile: Software Development Using Scrum by Mind Map: Succeeding With Agile: Software Development Using Scrum

1. Leading a Self Organizing Team

1.1. Containers

1.1.1. Change containers How does the team make decesions, change it Phyiscal space of the team

1.2. Differences

1.2.1. Ensure teams are diverse - amplify differences

1.3. Exchanges

1.3.1. Change how an exchange occurs

1.3.2. Add or remove people from exchange

1.3.3. Different meetings between different people

1.4. Influencing Evolution

1.4.1. Select the External Environment

1.4.2. Define Performance

1.4.3. Manage Meaning

1.4.4. Energize the System Give clear and elevating goals Crerate Project Charter Write product review and eleveator statement

2. Roles

2.1. Scrum Master

2.1.1. Personal Trainer Analogy They have the authority to keep you on the right track with the right exercises Ultimately has no authority over you. You make your own decisions on what to do

2.1.2. Keep team focused on goal "we're supposed to deliver potentially shipable software. What do we need to do next time to get 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

2.1.3. Attributes of Good Scrum Master Responsible Humble Collaborative Needs to create a collaborative environment for the team Committed Influential Clever and effective influence to get a team to try new things Influence others outside the team to help overcome roadblocks Knowledgeabble

2.1.4. Tech leads != Scrum Master teams should not have tech leads tech leads often make better team members Scrum Master does not have authority of the team so don't try to keep that authority by becoming the scrum master "my way or the highway" leads are bad Scrum Master candidates

2.2. Product Owner

2.2.1. 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

2.2.2. Each team needs exactly one product owner

2.2.3. Team of Product Owners for larger projects Needs to be one person per team, not a committe If a PO team members feels uncomfortable answering, there has to exist a PO lead to make the decision, not a committe

2.2.4. Attributes of Good Product Owner Available Business-savvy Communicative Decisive Empowered

2.3. Team Member / Programmer

2.3.1. 'OK' to have specialists, best to have the team work across the board

2.3.2. Need to become active participants in product requirements No longer being told what to do, need to understand what needs to be done

3. Technical Practices

3.1. Test Driven Development (TDD)

3.1.1. Evidence it takes 15% longer

3.1.2. Initial bugs reduced by over 25% long term bugs reduced ~ infinte

3.1.3. Try 'gang programming' for training 4-8 devs, 1 laptop, projector, pass the laptop every 15m

3.2. Refactoring

3.2.1. Objections If written/designed well wouldn't need it like saying if cars were made better, wouldn't need an oil change

3.2.2. Opportunistic Refactoring

3.2.3. Always leave the code better off than you found it

3.3. Collective Ownership

3.3.1. Ensure no dev becomes to specialized he can contribute only in one area

3.3.2. Make certain that no area becomes so intricate that it is understood only by one dev

3.3.3. Good ideas in one part of the application are more quickly proagated to other areas

3.3.4. Objections Development is faster if each person owns one part of the system in a very short term project - probably long term project - not true at all

3.4. Continuous Integration

3.4.1. Nightly builds 100% essential

3.4.2. Continuous nearly a must have no manual effort

3.5. Pair Programming

3.5.1. Objections Costs two devs to do the job one one Costs are deceiving In a hurry, we can't pair this is the most important time to pair then

3.5.2. Two team members at a single computer actively working tasks Can increase time to complete tasks by 10-15% Number of bugs reduced by over 50% Takes longer to do a task correctly than incorrectly

3.6. Design: Intentional yet Emergent

3.6.1. Emerging design is more productive than waterfall design

3.6.2. Requires rework often With sound technical practices like TDD, rework is easy and fast Rework leads to a best design to the project while upfront design can't successfully change without rework

3.7. Quality/Testing

3.7.1. Why testing at the end doesn't work It is hard to improve the quality of an existing product Mistakes continue unnoticed State of the project is difficult to gauge Feedback opportunities are lost Testing is more likely to be cut

3.7.2. Test Automation Pyramid UI Brittle Expensive to Write Time Consuming Service Unit

4. Team

4.1. Two Pizza Team

4.1.1. Smaller Teams Less social loafing Constructive interaction Less time spent coordinating Higher Participation More satisfying to the team Less chance for harmful over-specialization

4.1.2. Productivity Small teams are much more productive Large teams complete projects on average 12 days sooner than small teams Costs a lot more money and has a lot more defects

4.2. Favor Feature Teams

4.2.1. 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

4.2.2. Consider Component Teams ONLY if Component team will build something that will be used by multiple feature teams Desire to reduce the sharing of specialists Often feature teams run specialists thin they can't really be utelized in code Risk of multiple approaches outweighs disadvantages of component teams Multiple feature teams may need to solve the same problems in a sprint and thats a big risk of duplicated effort You can see an end to the need for component teams

4.3. Right People on the Team

4.3.1. Include all needed disciplines

4.3.2. Balance technical skill levels

4.3.3. Balance domain knowledge

4.3.4. Seek Diversity Don't want teams that come to quick conclusions Want teams that think through their conclusions thoroughly

4.3.5. Consider Persistence

4.4. Try not to multitask teammembers

4.4.1. Total work decreases the more required to multitask

4.4.2. Better to have a few members multitask a lot, than have the whole team multitask a little

4.5. Don't start a new project until it can be fully staffed

5. Product Backlog

5.1. Written Document Negatives

5.1.1. can make you suspend judgement

5.1.2. Leads to lack of conversation over meaning and overuse of assumptions

5.1.3. decrease whole-team responsibility

5.2. Use User Stories

5.2.1. As a <type of user>, I want <some goal> so that <some reason>

5.2.2. Promise to have a future discussion; not every detail required Team should practice communication skills w/ PO to speak about business not all technical

5.2.3. Add detail over time Conditions of Satisfaction Acceptance Criteria

5.3. Emergent Requirements are encouraged

5.4. Iceberg

5.4.1. Tip is known

5.4.2. Everything under water we know is there and its a lot but its not very detailed, we will get to it later

5.5. Grooming

5.5.1. 10% of effort in each sprint

5.6. Why progressively refine

5.6.1. Things will change Priorities shift New needs are discovered or solved

5.6.2. There's no need Items may be obsolete or unnecessesary as the project progresses

5.6.3. Time is scarce

5.6.4. Allows decisions to be made at the optimal time

5.6.5. Allows to make course changes

5.6.6. avoid falling into trap of believing our plans

5.7. Should be 'DEEP'

5.7.1. Detailed Appropriately

5.7.2. Estimated

5.7.3. Emergent

5.7.4. Prioritized

6. Sprint

6.1. Keep Timeboxes

6.1.1. Teams benefit from a regular cadence

6.1.2. Sprint planning becomes easier

6.1.3. Release planning becomes easier

6.2. Never Extend

6.2.1. Discourages the commitment

6.3. Don't Plan on Overtime to Salvage a Plan

6.3.1. Leads to poor quality Developers are forced to cut corners to meet poor estimates

6.3.2. Work a Sustainable Pace

6.3.3. XP Rule:you can't work a second week of overtime If needed, the project has a big problem

6.3.4. The only acceptable overtime is team concluded and desired overtime

6.3.5. If a commitment has too much focus the team will not commit to what they can do but often much less to confidently commit

6.4. Add Energy vs Overtime

6.4.1. Increase the passion around the project

6.4.2. Pomodoro technique 5 min breaks to every 25 min of work

6.5. Favor Scope Changes

6.5.1. Alternatives Cut Quality Add Resources Extend the Schedule

6.5.2. Shrinking scope is often acceptable to everyone and can have huge benefits and keep a project productive

7. Becoming Agile is Hard

7.1. Why Transition is Hard

7.1.1. Successful change is not entirely top-down or bottom-up

7.1.2. The end state is unpredicatable

7.1.3. Scrum is pervasive

7.1.4. Scrum is dramatically different Emergent Design vs Waterfall

7.1.5. Change is coming more quickly than ever before

7.1.6. Best practices are dangerous Each business has different needs, thus different practices Cannot plan every project with a rule book or best practices

7.2. Why it's worth the effort

7.2.1. Higher Productivity and lower costs

7.2.2. Improved employee engagement and job satisfaction

7.2.3. Faster time to market Could go to market after every sprint if desired

7.2.4. Higher quality

7.2.5. Improved stakeholder satisfaction

7.2.6. What we've been doing no longer works

8. Spreading Scrum

8.1. Split and Seed

8.1.1. Split a team after a few sprints into two teams, mixing the new teams with 'other' (new or otherwise) team members

8.1.2. Can add teams quickly

8.1.3. But destroys teams just starting to jell

8.2. Grow and Split

8.2.1. Grow a team into a large team, and then split the team into two teams. Continue to grow those teams and split again

8.2.2. Keeps teams together (mostly)

8.2.3. Most natural This would happen as projects grow

8.3. Internal Coaching

8.3.1. Successful team member helps another team while continuing to work on the original team

8.3.2. Keeps teams together entirely

8.3.3. Coaches can be hand selected Can move from one team to another

8.3.4. Attends: Sprint Planning Review Retrospective 1 Daily Scrum a Week 2 hours a week for other help

9. Iterate Toward Agility

9.1. Use Scrum to Apply/Adopt Scrum

9.2. Improvement(Product) Backlog

9.2.1. Example Items Enable teams to implement CI Create Awareness of Scrum on each Team Figure out how to make sure each team has a PO

9.2.2. Multiple backlogs for large companies

9.3. Enterprise Transition Community (ETC) (The Team)

9.3.1. Daily Scrums encouraged, not as important as development scrum teams

9.3.2. Responsiibilities Articulate the context Stimulate Conversation Provide resources Set appropriate aspirations Engage everyone

9.4. Sponsor (PO)

9.4.1. Probably an experienced PO, this is new

9.4.2. Doesn't have to be the sole PO, the ETC can help heavily Does need to be committed and apply time

9.4.3. Needs to be senior management/partner/co founder to help adoption

9.5. Form Improvement Communities

9.5.1. Like sub ETC teams where the/an ETC member is the PO

10. Pilot Project

10.1. Pilot != to decide to do it

10.1.1. Pilot = forge the way to understand the best approaches at the company

10.2. Picking best pilot project

10.2.1. Duration Whatever is near the 'middle' of what is normal Ideally ~3-4 months

10.2.2. Size Single Collcoated Team It may grow over time Keep growth under 5 teams

10.2.3. Importance Choose an important project Gives it best chance to over come roadblocks and not be called a unique/special case

10.2.4. Business sponsor engagement A good sponsor can help overcome external roadblocks Can champion the successes across the company

10.3. Manage Expectations

10.3.1. Most teams will over commit

10.3.2. Most teams will be more useful

10.3.3. Poor teams will get good fast Good teams may slow down at first, and be great in the end

10.3.4. Initial predictability will be poor Estimates will start out poor Teams take a few sprints to find a sustainable pace

10.3.5. Level of involvement PO and stakeholders have significant roles for the team to be successful. Don't underplay their need.

11. Overcoming Resistance

11.1. Skeptics

11.1.1. Provide training

11.1.2. Solicit peer anecdotes

11.1.3. Appoint champion skeptic Acknowledge the skeptic and go to him for alternate views to further conversation and tackle issues

11.1.4. Push the issue Challenge the skeptic to come up with iterative steps to solving the skeptic outlook

11.1.5. Let time run its course

11.2. Saboteur

11.2.1. Success Prove success on diverse projects

11.2.2. Reiterate and reinforce the commitment

11.2.3. Move them To a different project To a different type of role bye bye

11.2.4. Fire them bye bye

11.3. Diehards

11.3.1. Align incentives They are diehards for a reason - use that

11.3.2. Create dissatisfaction with the status quo

11.3.3. Acknowledge and confront fear


11.4.1. Change the composition of the team

11.4.2. Praise the right behavior

11.4.3. Involve them

11.4.4. Identify the true barrier

12. Scaling Scrum

12.1. Scaling the Product Owner

12.1.1. Keep a PO responsible for no more than 2 teams

12.1.2. Scaled Roles Chief Product Owner Product Line Owners Product Owners

12.2. Working w/ a Large Product Backlog

12.2.1. One Product, One Product Backlog

12.2.2. 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 single responsible view

12.3. Proactively Manage Dependencies

12.3.1. Do Rolling Lookahead Planning At the end of Sprint Planning Spend a few minutes discussing what each team will do in the next couple of sprints Help identify dependencies early

12.3.2. Hold a Release Kickoff Meeting Roughly plan 3 months out and discuss those goals with all teams so that everyone starts out on the same page

12.3.3. Share Team Members Part time team members

12.3.4. Use an Integration Team Best on projects with ten or more teams First goal is to analyze nightly build and solve any nightly build problems with the teams involved Integration Team Member at every other teams standard meetings

12.4. Coordinate Work Among Teams

12.4.1. 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 Are problem-solving meetings Agenda What has my team done since we last met that could affect other teams? What will my team do before we meet again that could affect other teams? What problems is my team having with which it could use help from other teams? No personal names used during this part As needed: Resolve problems and discuss items on an issues backlog

12.4.2. Synchronize Sprints Staggering sprints are a horrible idea Never a time when all teams are done 2 or 3 day stagger is acceptable on a large project Allows members to attend multiple meetings Remote members can attend all potentially useful meetings

12.5. Scaling Sprint Planning

12.5.1. Stagger by a Day Works for projects up to 9 teams

12.5.2. The Big Room Big room with all teams split into their own 'corners' and have normal individual sprint planning meetings Use nautical singaling flags for communication Need architect Need PO Time to order Lunch On a Break

12.6. Cultivate Communities of Practice

12.6.1. 'Test Community', 'programming community' 'ScrumMaster community', 'UI Community'

12.6.2. Virtual Architecture Team (VAT)

12.6.3. Can span more than one project

13. Distributed Teams

13.1. Create Coherence

13.1.1. Acknowledge Significant Cultural Differences Power Distance Index (PDI) Individualism (IND) Achievement Orientation (ACH) Uncertainty Avoidance Index (UAI) Long-Term Orientation (LTO)

13.1.2. Acknowledge the Small Cultural Differences

13.1.3. Strengthen Funcationl and Team Subcultures

13.1.4. Communicate and Establish a Shared Vision

13.1.5. Reach Agreements

13.1.6. Build trust by emphasizing early progress Focus on tasks first After learning about eachother with task progress and completion focus on relationship building

13.2. Get Together in person

13.2.1. Seeding Visits Maybe even seeding the first sprint

13.2.2. Contact Visits Focus around a task but the goal is relationship building One week visit for every couple of months

13.2.3. Traveling Ambassadoors Semi Permanent team member Stays for several months Rarely used this way so settle for shorter but more often visits Communicates Gossip Not malicious rumors Personal details that which aren't discussed in formal meetings 'Fernando's baby took her first steps last night' Communicate lessons learned

13.3. Change How You Communicate

13.3.1. User Stories Supplement with some more detail "Send a long a test" Add a high level test case that indicates if the story is complete

13.3.2. Encourage Lateral Conversion Combats the 'mum' effect

13.3.3. Include time for small talk Start telecons with chit chat Encourages culture and a better mood for the call

13.3.4. Telecons Share the pain Change meeting times monthly to make it fair among team members Have some meetings all by telecon, even the local members to show how difficult the phone call can be to stay engaged Tell Everyone who is talking State your name before speaking Have low-fidelity video conferencing Sprint Planning The Long Phone Call Two Calls

14. Outside Development Affects

14.1. Human Resources

14.1.1. Performance Reviews Eliminate individual factors how did the individual effectively manage tasks within budget and timeline Include teamwork factors Helps the team finish tasks within the timeline effectively applies retrospective items and helps others do the same Review more frequently than anually

14.1.2. Career Paths Scrum masters may rotate through different teams of importance Development team members may also rotate through different teams to share technical knowledge Role may also change on the team and initial tester/designer may rotate to bigger architectural inputs and implementation later on in the team