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. Becoming Agile is Hard

2.1. Why Transition is Hard

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

2.1.2. The end state is unpredicatable

2.1.3. Scrum is pervasive

2.1.4. Scrum is dramatically different Emergent Design vs Waterfall

2.1.5. Change is coming more quickly than ever before

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

2.2. Why it's worth the effort

2.2.1. Higher Productivity and lower costs

2.2.2. Improved employee engagement and job satisfaction

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

2.2.4. Higher quality

2.2.5. Improved stakeholder satisfaction

2.2.6. What we've been doing no longer works

3. Spreading Scrum

3.1. Split and Seed

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

3.1.2. Can add teams quickly

3.1.3. But destroys teams just starting to jell

3.2. Grow and Split

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

3.2.2. Keeps teams together (mostly)

3.2.3. Most natural This would happen as projects grow

3.3. Internal Coaching

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

3.3.2. Keeps teams together entirely

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

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

4. Iterate Toward Agility

4.1. Use Scrum to Apply/Adopt Scrum

4.2. Improvement(Product) Backlog

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

4.2.2. Multiple backlogs for large companies

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

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

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

4.4. Sponsor (PO)

4.4.1. Probably an experienced PO, this is new

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

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

4.5. Form Improvement Communities

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

5. Pilot Project

5.1. Pilot != to decide to do it

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

5.2. Picking best pilot project

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

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

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

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

5.3. Manage Expectations

5.3.1. Most teams will over commit

5.3.2. Most teams will be more useful

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

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

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

6. Overcoming Resistance

6.1. Skeptics

6.1.1. Provide training

6.1.2. Solicit peer anecdotes

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

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

6.1.5. Let time run its course

6.2. Saboteur

6.2.1. Success Prove success on diverse projects

6.2.2. Reiterate and reinforce the commitment

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

6.2.4. Fire them bye bye

6.3. Diehards

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

6.3.2. Create dissatisfaction with the status quo

6.3.3. Acknowledge and confront fear


6.4.1. Change the composition of the team

6.4.2. Praise the right behavior

6.4.3. Involve them

6.4.4. Identify the true barrier

7. Roles

7.1. Scrum Master

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

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

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

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

7.2. Product Owner

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

7.2.2. Each team needs exactly one product owner

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

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

7.3. Team Member / Programmer

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

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

8. Technical Practices

8.1. Test Driven Development (TDD)

8.1.1. Evidence it takes 15% longer

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

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

8.2. Refactoring

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

8.2.2. Opportunistic Refactoring

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

8.3. Collective Ownership

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

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

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

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

8.4. Continuous Integration

8.4.1. Nightly builds 100% essential

8.4.2. Continuous nearly a must have no manual effort

8.5. Pair Programming

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

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

8.6. Design: Intentional yet Emergent

8.6.1. Emerging design is more productive than waterfall design

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

8.7. Quality/Testing

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

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

9. Team

9.1. Two Pizza Team

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

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

9.2. Favor Feature Teams

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

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

9.3. Right People on the Team

9.3.1. Include all needed disciplines

9.3.2. Balance technical skill levels

9.3.3. Balance domain knowledge

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

9.3.5. Consider Persistence

9.4. Try not to multitask teammembers

9.4.1. Total work decreases the more required to multitask

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

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

10. Product Backlog

10.1. Written Document Negatives

10.1.1. can make you suspend judgement

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

10.1.3. decrease whole-team responsibility

10.2. Use User Stories

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

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

10.2.3. Add detail over time Conditions of Satisfaction Acceptance Criteria

10.3. Emergent Requirements are encouraged

10.4. Iceberg

10.4.1. Tip is known

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

10.5. Grooming

10.5.1. 10% of effort in each sprint

10.6. Why progressively refine

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

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

10.6.3. Time is scarce

10.6.4. Allows decisions to be made at the optimal time

10.6.5. Allows to make course changes

10.6.6. avoid falling into trap of believing our plans

10.7. Should be 'DEEP'

10.7.1. Detailed Appropriately

10.7.2. Estimated

10.7.3. Emergent

10.7.4. Prioritized

11. Sprint

11.1. Keep Timeboxes

11.1.1. Teams benefit from a regular cadence

11.1.2. Sprint planning becomes easier

11.1.3. Release planning becomes easier

11.2. Never Extend

11.2.1. Discourages the commitment

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

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

11.3.2. Work a Sustainable Pace

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

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

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

11.4. Add Energy vs Overtime

11.4.1. Increase the passion around the project

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

11.5. Favor Scope Changes

11.5.1. Alternatives Cut Quality Add Resources Extend the Schedule

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

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