Breaking down silos

Breaking down silos

My Tech4Africa 2011 talk on collaborative software development.

0b14c85d1c2e7e05fb9ea51dc9ea3098?s=128

Rian van der Merwe

October 27, 2011
Tweet

Transcript

  1. Rian van der Merwe twitter: @RianVDM web: elezea.com Breaking down

    silos Building better software through collaboration
  2. Siloed software development Isolation Lonely silos Functional silos

  3. Today’s topics What are the consequences of lonely silo development?

    What are the consequences of functional silo development? How can we do it better through collaboration?
  4. Today’s topics What are the consequences of lonely silo development?

    What are the consequences of functional silo development? How can we do it better through collaboration?
  5. The idea of minimum viable product is useful because you

    can basically say: our vision is to build a product that solves this core problem for customers. So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback. Lonely silos “ - Eric Reis 1. MVP madness
  6. Lonely silos 1. MVP madness

  7. Lonely silos 1. MVP madness [Color founder Bill Nguyen] outlined

    an ambitious plan to compete with Apple, Google and Facebook by tying together group messaging, recommendations and local search, all while making money through advertising. http://www.nytimes.com/2011/06/20/technology/20color.html
  8. Lonely silos 1. MVP madness

  9. None
  10. Lonely silos 1. MVP madness 2. No significant design focus

  11. Lonely silos 1. MVP madness 2. No significant design focus

  12. Lonely silos 1. MVP madness 2. No significant design focus

  13. The floor of Silicon Valley is littered with the crumbling

    husks of great ideas—useful products and services that died in the shell before they hatched out of their impenetrable engineering- specified interfaces. “ - Erika Hall (Mule Design) Lonely silos 1. MVP madness 2. No significant design focus
  14. Lonely silos 1. MVP madness 3. Endless cycles 2. No

    significant design focus “Are we done yet?” “Maybe.”
  15. Lonely silos 1. MVP madness 3. Endless cycles 2. No

    significant design focus Wave is a case in point. Wave started with some fairly easy to understand ideas about online collaboration and communication. But in order to make it more general and universal, more ideas were added until the entire thing could only be explained in a 90 minute mind blowing demo that left people speechless but a little later wondering what the hell this was for. “ - Douwe Osinga
  16. Today’s topics What are the consequences of lonely silo development?

    What are the consequences of functional silo development? How can we do it better through collaboration?
  17. Functional silos Global  Header  team   Daily  Deal   team

      Marke2ng   Finding   team   Merchandising   team   Product!   1. Org structure design
  18. Functional silos 1. Org structure design

  19. Functional silos Global  Header  team   Daily  Deal   team

      Marke2ng   Finding   team   Merchandising   team   Product!   Umm…  no  one?   1. Org structure design
  20. Functional silos It needs to be a little more Web

    2.0! The font should definitely change back to Comic Sans 2. Design monkeys 1. Org structure design
  21. Functional silos 2. Design monkeys 1. Org structure design 3.

    Tired developers
  22. Functional silos “Hmm, this is a non-trivial problem.” * Since

    no engineer is going to admit something is impossible, they use this word instead. When an engineer says something is "non-trivial," it's the equivalent of an airline pilot calmly telling you that you might encounter "just a bit of turbulence" as he flies you into a category 5 hurricane. - Charles Miller * 2. Design monkeys 1. Org structure design 3. Tired developers
  23. 2. Design monkeys Functional silos 1. Org structure design 3.

    Tired developers 4. Design by committee First rule of design feedback: what you’re looking at is not art. It’s not even close. It’s a business tool in the making and should be looked at objectively like any other business tool you work with. The right question is not, “Do I like it?” but “Does this meet our goals?” If it’s blue, don’t ask yourself whether you like blue. Ask yourself if blue is going to help you sell sprockets. Better yet: ask your design team. You just wrote your first feedback question. “ - Mike Monteiro
  24. The sensible answer is to listen, absorb, discuss, be able

    to defend any design decision with clarity and reason, know when to pick your battles and know when to let go. Respond to every piece of feedback Note what feedback is being incorporated Explain why feedback is not being taken Use the UX validation stack Functional silos 2. Design monkeys 1. Org structure design 3. Tired developers 4. Design by committee
  25. The user experience validation stack http://www.uxbooth.com/blog/winning-a-user-experience-debate/

  26. Today’s topics What are the consequences of lonely silo development?

    What are the consequences of functional silo development? How can we do it better through collaboration?
  27. 1. Make sure everyone understands the problem Collaborative software development

  28. Many senior leaders recognize the silo problem, but they solve

    it the wrong way: if one hierarchical approach to organizing their business doesn’t work, try another hierarchy. Don’t like the old silos? Create new ones. This dark tunnel leads to an even darker pit: the dreaded — and often horrifically ineffective — reorg. - Louis Rosenfeld Collaborative software development “
  29. 2. Empower teams to do great work Collaborative software development

  30. Maker

  31. Manager

  32. Collaborative software development The Maker’s Schedule When you're operating on

    the maker's schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That's no problem for someone on the manager's schedule. There's always something coming on the next hour; the only question is what. But when someone on the maker's schedule has a meeting, they have to think about it. - Paul Graham “
  33. Collaborative software development Chasing the Two Highs When the nerd

    sees a knot, they want to unravel it. Complete knot domination Chasing the Second High is where nerds earn their salary. If the First High is the joy of understanding, the Second High is the act of creation. If you want your nerd to rock your world by building something revolutionary, you want them chasing the Second High. 1 2 “ (From “Managing Nerds” by Michael Lopp)
  34. Collaborative software development How to help your nerd achieve the

    Second High Obsessively protect both your nerd’s time and space. The almost-constant quest of the nerd is managing all the crap that is preventing them from entering the Zone as they search for the Highs. Every single second you allow a nerd to remain in the Zone is a second where something miraculous can occur. 1 2
  35. Collaborative software development Start with two questions What is missing

    from your environment? How can we improve our culture? 1 2 (tip: start with meetings and email)
  36. Collaborative software development [As] a programmer you must have a

    series of wins, every single day. It is the Deus Ex Machina of hacker success. It is what makes you eager for the next feature, and the next after that. And a large team is poison to small wins. The nature of large teams is such that even when you do have wins, they come after long, tiresome and disproportionately many hurdles. And this takes all the wind out of them. Often when I shipped a feature it felt more like relief than euphoria. - Dhanji R. Prasanna “
  37. Collaborative software development A final note on developers Resource Person

  38. 3. Create a better design and development cycle (or, everyone

    gets a voice) Collaborative software development
  39. They are the developers who can design enough to appreciate

    what good design can do for their product even if it sometimes means having to deviate from the framework and put a little extra effort into customizing certain functionality. images: http://bit.ly/war-developers And they are the designers who learn how to think like a programmer when they design and develop an aesthetic that is better suited to deconstruction rather than composition. - Thomas Petersen
  40. Collaborative software development Two more questions How would you like

    to contribute to the product development process? What information do you need to start coding? 1 2
  41. Collaborative software development The goal: Right-fidelity specifications

  42. Collaborative software development Great idea Product Council (Intergalactic Product Force?)

    High-level prioritisation Product Manager ownership CEO CTO Head of Product Engineering Manager Head of Merchandising Head of Marketing Support Manager Head of Finance
  43. Collaborative software development Nothing is what happens when everyone has

    to agree. - Seth Godin “
  44. Collaborative software development Product should be a dictatorship, not consensus-driven.

    There are casualties, hurt feelings, angry users. But all of those things are necessary if you’re going to create something unique. The iPhone is clearly a vision of a single core team, or maybe even one man. It happened to be a good dream, and that device now dominates mobile culture. But it’s extremely unlikely Apple would have ever built it if they conducted lots of focus groups and customer outreach first. No keyboard? Please. - Michael Arrington “ On the one extreme (and I don’t agree completely with this statement):
  45. The Product Manager is The Decider

  46. To deliver measurable business results through product solutions that meet

    both market needs and company goals.
  47. Product Planning Product Marketing Strategic Product Management

  48. Collaborative software development Product Manager Developer Visual Designer UX Research

    Interaction Designer Content Strategist Developers
  49. 4. Document thoroughly Communicate widely Collaborative software development

  50. Collaborative software development Roles and responsibilities Roadmap and Prioritization process

    Product development process Goals and success metrics Talk to people about: 1 2 3 4
  51. None
  52. Publish everywhere, invite anyone

  53. 5. Prove that it works Collaborative software development

  54. Collaborative software development Share case studies Define a project to

    improve: Acquisition | Activation | Activity Benchmark and set goals Measure religiously Publish results, and don’t hide the failures Show how your efforts are making a difference 1 2 3 4 5
  55. Collaborative software development

  56. In summary What are the consequences of siloed development? Low

    quality software Less money How can collaborative software development be encouraged? Build the right environment Create the right amount of process Identify the decision makers Be as open as possible
  57. Rian van der Merwe twitter: @RianVDM web: elezea.com Breaking down

    silos Building better software through collaboration