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

1.1.1.1. How does the team make decesions, change it

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

1.4.4.1. Give clear and elevating goals

1.4.4.2. Crerate Project Charter

1.4.4.2.1. Write product review and eleveator statement

2. Roles

2.1. Scrum Master

2.1.1. Personal Trainer Analogy

2.1.1.1. They have the authority to keep you on the right track with the right exercises

2.1.1.2. Ultimately has no authority over you. You make your own decisions on what to do

2.1.2. Keep team focused on goal

2.1.2.1. "we're supposed to deliver potentially shipable software. What do we need to do next time to get that?"

2.1.2.2. CAN'T tell the team what to do

2.1.2.2.1. Not - "Tod reviews all code from now on"

2.1.2.2.2. Therefore is not responsible if the team fails

2.1.3. Attributes of Good Scrum Master

2.1.3.1. Responsible

2.1.3.2. Humble

2.1.3.3. Collaborative

2.1.3.3.1. Needs to create a collaborative environment for the team

2.1.3.4. Committed

2.1.3.5. Influential

2.1.3.5.1. Clever and effective influence to get a team to try new things

2.1.3.5.2. Influence others outside the team to help overcome roadblocks

2.1.3.6. Knowledgeabble

2.1.4. Tech leads != Scrum Master

2.1.4.1. teams should not have tech leads

2.1.4.2. tech leads often make better team members

2.1.4.3. Scrum Master does not have authority of the team so don't try to keep that authority by becoming the scrum master

2.1.4.4. "my way or the highway" leads are bad Scrum Master candidates

2.2. Product Owner

2.2.1. Responsibilities

2.2.1.1. Providing Vision

2.2.1.2. Providing Boundaries

2.2.1.2.1. Need x by June

2.2.1.2.2. Needs to run at twice the speed

2.2.1.3. Focused on Return on Investment (ROI)

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

2.2.3.1. Needs to be one person per team, not a committe

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

2.2.4.1. Available

2.2.4.2. Business-savvy

2.2.4.3. Communicative

2.2.4.4. Decisive

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

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

3.1.2.1. long term bugs reduced ~ infinte

3.1.3. Try 'gang programming' for training

3.1.3.1. 4-8 devs, 1 laptop, projector, pass the laptop every 15m

3.2. Refactoring

3.2.1. Objections

3.2.1.1. If written/designed well wouldn't need it

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

3.3.4.1. Development is faster if each person owns one part of the system

3.3.4.1.1. in a very short term project - probably

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

3.4.2.1. no manual effort

3.5. Pair Programming

3.5.1. Objections

3.5.1.1. Costs two devs to do the job one one

3.5.1.1.1. Costs are deceiving

3.5.1.2. In a hurry, we can't pair

3.5.1.2.1. this is the most important time to pair then

3.5.2. Two team members at a single computer actively working tasks

3.5.2.1. Can increase time to complete tasks by 10-15%

3.5.2.1.1. Number of bugs reduced by over 50%

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

3.6.2.1. With sound technical practices like TDD, rework is easy and fast

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

3.7.1.1. It is hard to improve the quality of an existing product

3.7.1.2. Mistakes continue unnoticed

3.7.1.3. State of the project is difficult to gauge

3.7.1.4. Feedback opportunities are lost

3.7.1.5. Testing is more likely to be cut

3.7.2. Test Automation Pyramid

3.7.2.1. UI

3.7.2.1.1. Brittle

3.7.2.1.2. Expensive to Write

3.7.2.1.3. Time Consuming

3.7.2.2. Service

3.7.2.3. Unit

4. Team

4.1. Two Pizza Team

4.1.1. Smaller Teams

4.1.1.1. Less social loafing

4.1.1.2. Constructive interaction

4.1.1.3. Less time spent coordinating

4.1.1.4. Higher Participation

4.1.1.5. More satisfying to the team

4.1.1.6. Less chance for harmful over-specialization

4.1.2. Productivity

4.1.2.1. Small teams are much more productive

4.1.2.2. Large teams complete projects on average 12 days sooner than small teams

4.1.2.2.1. Costs a lot more money and has a lot more defects

4.2. Favor Feature Teams

4.2.1. Feature Team Benefits

4.2.1.1. Better able to evaluate design decisions

4.2.1.2. Reduce waste

4.2.1.3. Ensures the right people are talking

4.2.1.4. Less risk to the schedule

4.2.1.5. Keeps focus on delivering features

4.2.2. Consider Component Teams ONLY if

4.2.2.1. Component team will build something that will be used by multiple feature teams

4.2.2.2. Desire to reduce the sharing of specialists

4.2.2.2.1. Often feature teams run specialists thin they can't really be utelized in code

4.2.2.3. Risk of multiple approaches outweighs disadvantages of component teams

4.2.2.3.1. Multiple feature teams may need to solve the same problems in a sprint and thats a big risk of duplicated effort

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

4.3.4.1. Don't want teams that come to quick conclusions

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

5.2.2.1. Team should practice communication skills w/ PO to speak about business not all technical

5.2.3. Add detail over time

5.2.3.1. Conditions of Satisfaction

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

5.6.1.1. Priorities shift

5.6.1.2. New needs are discovered or solved

5.6.2. There's no need

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

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

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

6.4.2.1. 5 min breaks to every 25 min of work

6.5. Favor Scope Changes

6.5.1. Alternatives

6.5.1.1. Cut Quality

6.5.1.2. Add Resources

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

7.1.4.1. Emergent Design vs Waterfall

7.1.5. Change is coming more quickly than ever before

7.1.6. Best practices are dangerous

7.1.6.1. Each business has different needs, thus different practices

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

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

8.2.1.1. Continue to grow those teams and split again

8.2.2. Keeps teams together (mostly)

8.2.3. Most natural

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

8.3.3.1. Can move from one team to another

8.3.4. Attends:

8.3.4.1. Sprint Planning

8.3.4.2. Review

8.3.4.3. Retrospective

8.3.4.4. 1 Daily Scrum a Week

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

9.2.1.1. Enable teams to implement CI

9.2.1.2. Create Awareness of Scrum on each Team

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

9.3.2.1. Articulate the context

9.3.2.2. Stimulate Conversation

9.3.2.3. Provide resources

9.3.2.4. Set appropriate aspirations

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

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

10.2.1.1. Whatever is near the 'middle' of what is normal

10.2.1.1.1. Ideally ~3-4 months

10.2.2. Size

10.2.2.1. Single Collcoated Team

10.2.2.2. It may grow over time

10.2.2.2.1. Keep growth under 5 teams

10.2.3. Importance

10.2.3.1. Choose an important project

10.2.3.2. Gives it best chance to over come roadblocks and not be called a unique/special case

10.2.4. Business sponsor engagement

10.2.4.1. A good sponsor can help overcome external roadblocks

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

10.3.3.1. Good teams may slow down at first, and be great in the end

10.3.4. Initial predictability will be poor

10.3.4.1. Estimates will start out poor

10.3.4.2. Teams take a few sprints to find a sustainable pace

10.3.5. Level of involvement

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

11.1.3.1. Acknowledge the skeptic and go to him for alternate views to further conversation and tackle issues

11.1.4. Push the issue

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

11.2.1.1. Prove success on diverse projects

11.2.2. Reiterate and reinforce the commitment

11.2.3. Move them

11.2.3.1. To a different project

11.2.3.2. To a different type of role

11.2.3.3. bye bye

11.2.4. Fire them

11.2.4.1. bye bye

11.3. Diehards

11.3.1. Align incentives

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

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

12.1.2.1. Chief Product Owner

12.1.2.2. Product Line Owners

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

12.2.2.1. 100-150 responsible items

12.2.2.1.1. Robin Dunbar research

12.2.2.2. Use eipcs and themes

12.2.2.3. Use different views

12.2.2.3.1. Can have more than 150 but not in a single responsible view

12.3. Proactively Manage Dependencies

12.3.1. Do Rolling Lookahead Planning

12.3.1.1. At the end of Sprint Planning

12.3.1.2. Spend a few minutes discussing what each team will do in the next couple of sprints

12.3.1.3. Help identify dependencies early

12.3.2. Hold a Release Kickoff Meeting

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

12.3.3.1. Part time team members

12.3.4. Use an Integration Team

12.3.4.1. Best on projects with ten or more teams

12.3.4.2. First goal is to analyze nightly build and solve any nightly build problems with the teams involved

12.3.4.3. Integration Team Member at every other teams standard meetings

12.4. Coordinate Work Among Teams

12.4.1. Scrum of Scrums Meeting

12.4.1.1. 1 team member chosen by the team

12.4.1.1.1. if small # of teams perhaps 2 from each team

12.4.1.1.2. chosen members can rotate

12.4.1.2. Recursive; multiple levels of scrum of scrums

12.4.1.3. Frequency

12.4.1.3.1. Don't need to be daily

12.4.1.3.2. Dont need to be timeboxed to 15min

12.4.1.3.3. Are problem-solving meetings

12.4.1.4. Agenda

12.4.1.4.1. What has my team done since we last met that could affect other teams?

12.4.1.4.2. What will my team do before we meet again that could affect other teams?

12.4.1.4.3. What problems is my team having with which it could use help from other teams?

12.4.1.4.4. No personal names used during this part

12.4.1.4.5. As needed: Resolve problems and discuss items on an issues backlog

12.4.2. Synchronize Sprints

12.4.2.1. Staggering sprints are a horrible idea

12.4.2.1.1. Never a time when all teams are done

12.4.2.2. 2 or 3 day stagger is acceptable on a large project

12.4.2.2.1. Allows members to attend multiple meetings

12.4.2.2.2. Remote members can attend all potentially useful meetings

12.5. Scaling Sprint Planning

12.5.1. Stagger by a Day

12.5.1.1. Works for projects up to 9 teams

12.5.2. The Big Room

12.5.2.1. Big room with all teams split into their own 'corners' and have normal individual sprint planning meetings

12.5.2.2. Use nautical singaling flags for communication

12.5.2.2.1. Need architect

12.5.2.2.2. Need PO

12.5.2.2.3. Time to order Lunch

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

13.1.1.1. Power Distance Index (PDI)

13.1.1.2. Individualism (IND)

13.1.1.3. Achievement Orientation (ACH)

13.1.1.4. Uncertainty Avoidance Index (UAI)

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

13.1.6.1. Focus on tasks first

13.1.6.2. After learning about eachother with task progress and completion focus on relationship building

13.2. Get Together in person

13.2.1. Seeding Visits

13.2.1.1. Maybe even seeding the first sprint

13.2.2. Contact Visits

13.2.2.1. Focus around a task but the goal is relationship building

13.2.2.2. One week visit for every couple of months

13.2.3. Traveling Ambassadoors

13.2.3.1. Semi Permanent team member

13.2.3.2. Stays for several months

13.2.3.2.1. Rarely used this way so settle for shorter but more often visits

13.2.3.3. Communicates Gossip

13.2.3.3.1. Not malicious rumors

13.2.3.3.2. Personal details that which aren't discussed in formal meetings

13.2.3.3.3. 'Fernando's baby took her first steps last night'

13.2.3.4. Communicate lessons learned

13.3. Change How You Communicate

13.3.1. User Stories

13.3.1.1. Supplement with some more detail

13.3.1.2. "Send a long a test"

13.3.1.2.1. Add a high level test case that indicates if the story is complete

13.3.2. Encourage Lateral Conversion

13.3.2.1. Combats the 'mum' effect

13.3.3. Include time for small talk

13.3.3.1. Start telecons with chit chat

13.3.3.1.1. Encourages culture and a better mood for the call

13.3.4. Telecons

13.3.4.1. Share the pain

13.3.4.1.1. Change meeting times monthly to make it fair among team members

13.3.4.1.2. Have some meetings all by telecon, even the local members to show how difficult the phone call can be to stay engaged

13.3.4.2. Tell Everyone who is talking

13.3.4.2.1. State your name before speaking

13.3.4.2.2. Have low-fidelity video conferencing

13.3.4.3. Sprint Planning

13.3.4.3.1. The Long Phone Call

13.3.4.3.2. Two Calls

14. Outside Development Affects

14.1. Human Resources

14.1.1. Performance Reviews

14.1.1.1. Eliminate individual factors

14.1.1.1.1. how did the individual effectively manage tasks within budget and timeline

14.1.1.2. Include teamwork factors

14.1.1.2.1. Helps the team finish tasks within the timeline

14.1.1.2.2. effectively applies retrospective items and helps others do the same

14.1.1.3. Review more frequently than anually

14.1.2. Career Paths

14.1.2.1. Scrum masters may rotate through different teams of importance

14.1.2.2. Development team members may also rotate through different teams to share technical knowledge

14.1.2.2.1. Role may also change on the team and initial tester/designer may rotate to bigger architectural inputs and implementation later on in the team