Your SlideShare is downloading. ×
Breaking Down Knowledge Silos
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Breaking Down Knowledge Silos

1,687
views

Published on

Barriers are created all the time on software projects (by organization layout, role definition, project management, or indiscriminately) that keep developer knowledge separate. We can create better …

Barriers are created all the time on software projects (by organization layout, role definition, project management, or indiscriminately) that keep developer knowledge separate. We can create better teams and products for our organizations if we can blow up these silos.

Published in: Technology

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

  • Be the first to like this

No Downloads
Views
Total Views
1,687
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
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
  • Because silos can also bemissle silos, producing this shock and awe
  • - Silo: Barriers that have been created (by organization layout, role definition, project management, or indiscriminately) that keep something separate- Developer knowledge
  • Every developer has a unique experience with the software they work onMuch of that can be useful to other developers, present and future
  • In the end, highest priority is delivery of quality software that meets the needs of the customerThis can be done with very stringent silos, but we want to raise the odds of meeting that goal by taking them down, allowing developers to gain bits of the knowledge that others, possibly more familiar with the app, have already gained
  • This could be you or someone else; Bad if it’s you, obviously; Bad if it’s someone else, because now you have their work to do How do people get run over: horrible accidents, funding changes, new projects, new jobs, and more horrible accidents
  • Good for you and good for the project: Decrease the chances that you’ll be the one getting the late night phone call: - The code has had more eyes all over it, it’s hopefully more stable - The call could go to anyone because anyone should be able to fix it
  • Like manure at the farm Likelihood that the team that will eventually maintain the product will receive one or some of the original developers Developers have great knowledge of many systems (or in the case of MMS, the universe of msny mgmt as a whole).
  • - Mention of ping pong pair prg’ing? owner rotation ideas: day, half day- Present other ideas for pair programming, maybe general principles: New pair every iteration, owners (knowledge transfer’ers) have to be someone who has worked on it at any time during the project – most recent makes the most sense
  • Each dev owns storiesDedicates some time to helping the other pair member on their stories
  • And gets help in returnEach teach and learn
  • A mess if we try to map it out
  • More organicJust happens
  • - Developer-driven
  • - The idea that I have in my head is where developers feel responsible for the stories they have and for the product as a whole, and they realize that total health will be bettered long-term as the tribal knowledge of the product is spread around.
  • - Finishable in a day- Well-defined
  • Dev/mgmt – willing to tackle / willing to assign anything to anybody Strikes fear: Mevl/moderation/CPF/Script*/Letters/Transfer Override/SeniorAssignmentMeetingBean/FormProcessingServlet
  • - Feel pride for your work – which is now everything
  • Consider how you can open knowledge silos you’ve been privy toConsider what silos you don’t but should probably know something aboutConsider how you’ll influence the organization to form fewer silos
  • Transcript

    • 1. Breaking DownKnowledge Silos
      Within a Software Project
      Fun with Jake Trent
    • 2. Blowing upKnowledge Silos
      Within a Software Project
      More! fun with Jake Trent
    • 3. What is in the silo
    • 4. Developer Knowledge
      Business requirements
      How the code works
      Design, paradigms
      The why
      Pitfalls
    • 5. Why you want to blow stuff up
    • 6. Customer Smiles
      Better product
      Meets requirement
      Best practices
      Stable
      Maintainable
    • 7. Truck Factor
      Number of people that need to be run over before your project’s in trouble
    • 8. Helpful Team Members
      Versatile
      No problems beyond your ability
    • 9. Limit Liability
      No single point of failure
    • 10. Maintenance
      Spread across teams
    • 11. How the team can help
    • 12. dev / mgmt
      Pair Programming
      Devs talking to devs
      Pairs change more
    • 13. dev / mgmt
      Pair Programming
      Owner-Visitor
    • 14. c
      Stories
      c
      Stories
    • 15. c
      Stories
      c
      Stories
    • 16. c
      c
      Stories
      Stories
      c
      c
      Stories
      Stories
    • 17. dev / mgmt
      Culture
      Developer-driven
    • 18. dev
      Introspective
      What don’t I know about?
      What’s high risk?
      What’s highest priority?
      What’s the hardest/easiest? Why?
      What has the least/most bugs? Why?
      What’s behind/ahead of schedule? Why?
    • 19. dev / mgmt
      Mental Picture
      Story owners
      More fluid partnerships
    • 20. dev / mgmt
      Tasks
      Well-defined
      Small
    • 21. dev / mgmt
      Fear
      …leads to suffering
    • 22. dev
      Ownership
      Total product
    • 23. Now, go blow up some silos!
      (Knowledge silos only)
      rockycode.com/blog/tech/project-management/
      Attributions:
      Silos image (modified)- CC Attribution - http://www.flickr.com/photos/see-through-the-eye-of-g/4283298553/in/photostream/
      Explosion image (modified) - Public domain - http://www.flickr.com/photos/ctbto/4926598654/
      Menkaya font - free - http://www.dafont.com/menkaya.font
      YolksEmoticons font - free, non-commercial - http://www.dafont.com/yolks-emoticons.font