• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Scrum And The Enterprise
 

Scrum And The Enterprise

on

  • 1,242 views

 

Statistics

Views

Total Views
1,242
Views on SlideShare
1,231
Embed Views
11

Actions

Likes
0
Downloads
19
Comments
0

3 Embeds 11

http://www.linkedin.com 5
https://www.linkedin.com 4
http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Scrum And The Enterprise Scrum And The Enterprise Presentation Transcript

    • Scaling Scrum Adapted from The Enterprise And Scrum by Ken Schwaber
    • James Peckham
      • In IT since 2003
      • Support, Infrastructure, Networking, Development, Testing.
      • C#, Web services, WCF, WPF, ASP.NET, C++, Java, LPC, Lua, DirectX, XNA
    • Organizational Practices
      • Strategy
      • Operations
      • Projects
      • Lean
    • Strategic Plans
      • Existing organization product owner voice only considers 10,000 foot view items
      • Work items all become priority #1!
      • Incremental spans quarters instead of rapid feedback loops needed for true agility and to expose real roadblocks.
    • Operations work
      • Operations work is done by development departments inside of the project work loop
    • The meeting madness
      • A meeting to communicate some ideas to a manager
      • Who meets with the worker to communicate the ideas to worker
      • Who meets with vendor to communicate ideas with vendor
      • Who meets with…
    • Lean
      • Cutting back on waste
      • Closer communication with requestor to the worker creating the product.
      • Closer communication with Ops those doing the work.
      • Functional managers see their roles change
        • Less command
        • More removing organizational roadblocks
        • Making sure the worker is in contact with the source of work.
      • Some functional managers may find themselves “bored” but given opportunity to monitor and improve their team.
    • Operational Work
      • Driven By network operations
      • Driven by support ticketing
      • Driven by work orders
        • Work orders better communicated to workers who own them.
      • Driven by Configuration Management System
    • Project work
      • Baseline hours set by scrum team velocities and backlog item sizes
      • Enterprise wide ‘ideal day’ = story point
      • Enterprise wide ‘done’
        • Unit test
        • Security scan
        • Code review
        • Documentation level/template
      • Managed by enterprise backlog
    • Enterprise Backlog
      • Arranging work
        • Enterprise
        • Line of business
        • Operation
        • Product
        • Activity
        • System
        • Component
        • Requirement
    • Enterprise Product backlog
    • Engineering practices
        • Integrating often
          • Integrate at least once per sprint (30 days)
          • Difficult for engineering organizations especially those who have long running regression tests.
        • Multi layer system work organized by functionality
          • Create a local version utilizing existing infrastructure
          • Refactor to use new infrastructure development
    • Integration of Multiple-layer systems
      • Layer vs tier
      • Interface changes need communicated at scrum meeting(standup) in scrum of scrums
      • A team focused around each area of the system
      • Or each tier
      • An integration layer team (if not the UI team)
    • Integrating with non-scrum work
      • Stubbed/simulated systems
      • Simulated interfaces act as ongoing update to the Statement of work with the provider.
    • People practices
      • Organizing people to do enterprise work
      • Team creation
      • Team work
      • How people are managed
      • Functional expertise
      • Compensation
      • Extra managers
      • Teams with distributed members
      • Scarce skills needed by many teams
    • 30 years in the making
      • Functional managers
      • Departmentalized
      • Matrix organizations
      • Consider this on your own merit
      • Then consider steps needed to adopt
    • Organizing people to do the work
    • Organizing the people
      • The integration team is developing integration tests to verify all of the functionality integrates properly.
      • They’re the final say in whether the software is Demo-able or not. Generally a group of team leads from the different functional areas.
    • Team creation
      • Scrum master and product owner first
      • People who have succesfully worked together previously
      • People who understand the product or business domain
      • People who know the selected technology
      • People who can fulfill the ‘done’ requirement. For example a tech writer for documentation.
    • Self directed
      • 45 crossfunctional ‘developers’ at Woodgrove bank
        • They were all thrown in a room with no managers
        • Told follow scrum rules to organize into teams
      • Trust from team that management wasn’t ‘selling them down the river’
      • Trust from management
      • Self organizing will flourish
    • Team Work
      • Forming
      • Storming
      • Norming
      • Performing
    • forming
      • Decide how they’ll get requirements
      • Decide how they’ll test
      • Formed rules of etiquette (Working agreements/values)
      • Formed rules on engineering practices
      • Tentatively formalize sprint process for turning backlog items into something “Done”
    • storming
      • Team needs trained on resolving conflicts.
      • Conflicts about how things are done
      • Conflicts about who does things
      • They also need to be able to identify the source of their conflicts and not blame
        • No ‘You’ language, try “It” or “we”
        • No “But” language, try “and”
    • Norming and performing
      • Performing is not permanent.
      • Storming will arise from time to time.
      • When it does they will need the skills to identify the cause and resolve it.
    • How people are managed
      • The team manages it self
      • The product owner sets goals
      • The team commits
      • The scrum master ensures the ‘framework’ of scrum is followed
      • The rules of the organization cannot be ignored.
        • Enterprise “Done”
    • The product owner
      • Responsible for node one of the tree and setting goals. Responsible for ROI
    • The scrum master
      • At node 1 the scrum master should be educating the product owner on how to maximize ROI utilizing the scrum framework
      • Scrum master should be making sure all scrum masters in below nodes are encouraging self direction.
    • Functional expertise
      • How do I keep functional skills sharp now that functional managers are scrum masters?
      • You could let ‘the team decide’ or…
    • 20% to ‘self research’
      • Or allow them to dedicate 20% to self research and improving themselves.
        • Don’t just say “Seek training”
        • Remember your teacher: “Write me a paper” and you said “How long does it have to be?”
      • Be surprised like 3m and Google were!
        • Gmail… PostIts….
    • compensation
      • Total incentive amount pooled and sent down through the teams via the product owner.
      • Meeting commitments
      • Teamwork
      • Collaboration
      • Communication
    • Extra managers
      • Some managers left over after all were assigned as scrum masters
      • Idle hands are the devil’s workshop
      • Managers attending sprint planning
        • Committing for team members
      • Managers assigning work
      • Managers making sure there was no slack time
    • Teams with distributed members
      • We can’t collocate our team 
        • Can you simulate it? Yes!
          • Intercom/immediate chat
            • Teamspeak
            • Ventrilo
            • Voip systems
        • Sync up with representatives from each office.
        • Let the team brainstorm!
    • Scarce skills needed by many teams
      • Cross-training
      • Share time
      • Let the team decide
      • Don’t let the shared resource work in isolation.
        • Their knowledge won’t get shared
        • No accountability to a team
    • Relationship between Product manager and the dev team
      • Shortening the time to release through managing value
      • Just do it
      • The infrastructure
      • Accelerators to recovery
      • The mother of all problems
    • Delivering value
      • Backlog items can be measured in ROI
      • Product owners can determine what value they are delivering and deliver highest value first
      • Projects ending before the unused features even get delivered… move on to other projects.
    • Relative valuation
      • 1000 ping pong balls
      • Place them into all the backlog items of the project.
      21 32 item 33 12 50 item 32 … … … 13 60 item 9 22 60 item 8 20 65 item 7 13 70 item 6 34 70 item 5 13 74 item 4 21 75 item 3 34 75 item 2 13 80 item 1 effort value backlog
    • Earned business value
    • Just do it
      • Time honored tradition
      • Tells managers, devs aren’t on board!
      • Devs cut quality!
      • Speed is improved up to 3x!
      • Maintenance cost can go upwards of 4x more.
      • Decrease value of enterprise asset
    • The core
      • The core constraint
      • How did this happen?
      • The product owner meeting!
        • All the core engineers and product owners in the room
    • Accelerators
      • How do I move this beast faster!
      • Remediate the core
        • Develop automation
        • Form teams and refactor it aggressively
      • Strangle the core
        • As bugs are fixed refactor, clean, and heavily comment code
      • Rewrite the core
        • Wee!
      • Prop up the core
        • Live with it longer but put automation around it to tell when it breaks.
      • Drain the pond
        • Rebuild with new tech and good design with test harnesses.
    • How did this happen?
      • “just do it”
      • Bad engineering practices
      • Choice to hit market fast
    • How can we see when this is happening?
      • Trending of slower velocities over time.
    • google
      • http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
      • I don’t know steve but let’s talk about what he points out as ‘signs’ of good agility.
    • Signs of good agility in play
      • No true managers, just team leads
      • Peer reviews influence the team
      • Goals are communicated through an incentive system (I would imagine an enterprise product backlog with highest value giving highest incentive for completing)
      • Meetings are reduced to 1-3/week
      • Meetings only happen in the middle of the day so people can do what they need to do early or late.
        • It also ensures that late or early comers always get ‘meetings’ that are needed
        • Note they have free meals for everyone so that would help the meeting during mid-day situations.