Succeeding With Agile: Software Development Using Scrum
Leading a Self Organizing Team
Containers
Change conotainers, 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
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 Improve 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
Skeptics
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
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
Roles
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 projjects, 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
Refactoring
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
Quality/Testing
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
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 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
Iceberg
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
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 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
Estimated
Emergent
Prioritized
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 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
