Create your own awesome maps

Even on the go

with our free apps for iPhone, iPad and Android

Get Started

Already have an account?
Log In

Succeeding With Agile: Software Development Using Scrum by Mind Map: Succeeding With Agile: Software
Development Using Scrum
5.0 stars - 5 reviews range from 0 to 5

Succeeding With Agile: Software Development Using Scrum

Leading a Self Organizing Team


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


Ensure teams are diverse - amplify differences


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

Becoming Agile is Hard

Why Transition is Hard

Successful change is not entirely top-down or bottom-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, thus different practices, Cannot plan every project with a rule book or best practices

Why it's worth the effort

Higher Productivity and lower costs

Improved employee engagement and job satisfaction

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

Spreading Scrum

Split and Seed

Split a team after a few sprints into two teams, mixing the new teams with 'other' (new or otherwise) 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 split the 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 team while 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

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 a PO

Multiple backlogs for large companies

Enterprise Transition Community (ETC) (The Team)

Daily Scrums encouraged, not as important as development 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 can help heavily, Does need to be committed and apply time

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

Form Improvement Communities

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

Pilot Project

Pilot != to decide to do it

Pilot = forge the way to understand the best 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 roadblocks and not be called a unique/special case

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

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 be great in the end

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

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

Overcoming Resistance


Provide training

Solicit peer anecdotes

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

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

Let time run its course


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


Align incentives, They are diehards for a reason - use that

Create dissatisfaction with the status quo

Acknowledge and confront fear


Change the composition of the team

Praise the right behavior

Involve them

Identify the true barrier


Scrum Master

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

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, 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 environment for the team, Almost like a good teacher, Be willing to do what is necessary to open the team up and communicate effectively, Committed, Influential, Clever and effective influence to get a team to try new things, Not a 'because I say so' style, Influence others outside the team to help overcome 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 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

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 a committe, If a PO team members feels uncomfortable answering, there has to exist a PO lead to make 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 team work across the board

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

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 the laptop every 15m


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

Opportunistic Refactoring

Always leave the code better off than you found it

Collective Ownership

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

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

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

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

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 outweigh man 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 repeat it, Studies prove your faster to market when pairing

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

Design: Intentional yet Emergent

Emerging design is more productive than waterfall design

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


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

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


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 12 days sooner than small teams, Costs a lot more money and has a lot more defects

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

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 conclusions thoroughly

Consider Persistence

Try not to multitask teammembers

Total work decreases the more required to multitask

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 fully staffed

Product Backlog

Written Document Negatives

can make you suspend judgement

Leads to lack of conversation over meaning and overuse 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 every detail required, Team should practice communication skills w/ PO to speak about business not all technical

Add detail over time, Conditions of Satisfaction, Acceptance Criteria

Emergent Requirements are encouraged


Tip is known

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


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 the project 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





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 meet poor estimates

Work a Sustainable Pace

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

The only acceptable overtime is team concluded and desired overtime

If a commitment has too much focus the team will not commit to what they can do but often much 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 everyone and can have huge benefits and keep a project productive

Scaling Scrum

Scaling the Product Owner

Keep a PO responsible for no more than 2 teams

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

Proactively Manage Dependencies

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

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

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 solve any nightly build problems with the teams involved, Integration Team Member at every other teams standard 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 the problem then and there, 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, 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 ask others for help, 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

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 sprint planning 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

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 task progress and completion focus on relationship building

Get Together in person

Seeding Visits, Maybe even seeding the first sprint

Contact Visits, Focus around a task but the goal is relationship building, 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 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

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 the story 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 the call

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, Have pictures with names and have someone hold it up when they recognize the persons voice, Sprint Planning, The Long Phone Call, Two Calls

Outside Development Affects

Human Resources

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

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