Your SlideShare is downloading. ×
Scrum And The Enterprise
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Scrum And The Enterprise

721

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
721
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
20
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Scaling Scrum Adapted from The Enterprise And Scrum by Ken Schwaber
  • 2. James Peckham
    • In IT since 2003
    • Support, Infrastructure, Networking, Development, Testing.
    • C#, Web services, WCF, WPF, ASP.NET, C++, Java, LPC, Lua, DirectX, XNA
  • 3. Organizational Practices
    • Strategy
    • Operations
    • Projects
    • Lean
  • 4. 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.
  • 5. Operations work
    • Operations work is done by development departments inside of the project work loop
  • 6. 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…
  • 7. 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.
  • 8. 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
  • 9. 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
  • 10. Enterprise Backlog
    • Arranging work
      • Enterprise
      • Line of business
      • Operation
      • Product
      • Activity
      • System
      • Component
      • Requirement
  • 11. Enterprise Product backlog
  • 12. 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
  • 13. Integration of Multiple-layer systems
    • Layer vs tier
    • Interface changes need communicated at scrum meeting(standup) in scrum of scrums
  • 14.
    • A team focused around each area of the system
    • Or each tier
    • An integration layer team (if not the UI team)
  • 15. Integrating with non-scrum work
    • Stubbed/simulated systems
    • Simulated interfaces act as ongoing update to the Statement of work with the provider.
  • 16. 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
  • 17. 30 years in the making
    • Functional managers
    • Departmentalized
    • Matrix organizations
    • Consider this on your own merit
    • Then consider steps needed to adopt
  • 18. Organizing people to do the work
  • 19. 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.
  • 20. 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.
  • 21. 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
  • 22. Team Work
    • Forming
    • Storming
    • Norming
    • Performing
  • 23. 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”
  • 24. 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”
  • 25. 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.
  • 26. 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”
  • 27. The product owner
    • Responsible for node one of the tree and setting goals. Responsible for ROI
  • 28. 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.
  • 29. Functional expertise
    • How do I keep functional skills sharp now that functional managers are scrum masters?
    • You could let ‘the team decide’ or…
  • 30. 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….
  • 31. compensation
    • Total incentive amount pooled and sent down through the teams via the product owner.
    • Meeting commitments
    • Teamwork
    • Collaboration
    • Communication
  • 32. 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
  • 33. 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!
  • 34. 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
  • 35. 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
  • 36. 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.
  • 37. 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
  • 38. Earned business value
  • 39. 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
  • 40. The core
    • The core constraint
    • How did this happen?
    • The product owner meeting!
      • All the core engineers and product owners in the room
  • 41. 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.
  • 42. How did this happen?
    • “just do it”
    • Bad engineering practices
    • Choice to hit market fast
  • 43. How can we see when this is happening?
    • Trending of slower velocities over time.
  • 44. 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.
  • 45. 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.

×