Slide 1

Slide 1 text

Rian van der Merwe twitter: @RianVDM web: elezea.com Breaking down silos Building better software through collaboration

Slide 2

Slide 2 text

Siloed software development Isolation Lonely silos Functional silos

Slide 3

Slide 3 text

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?

Slide 4

Slide 4 text

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?

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Lonely silos 1. MVP madness

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Lonely silos 1. MVP madness

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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?

Slide 17

Slide 17 text

Functional silos Global  Header  team   Daily  Deal   team   Marke2ng   Finding   team   Merchandising   team   Product!   1. Org structure design

Slide 18

Slide 18 text

Functional silos 1. Org structure design

Slide 19

Slide 19 text

Functional silos Global  Header  team   Daily  Deal   team   Marke2ng   Finding   team   Merchandising   team   Product!   Umm…  no  one?   1. Org structure design

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

Functional silos 2. Design monkeys 1. Org structure design 3. Tired developers

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

The user experience validation stack http://www.uxbooth.com/blog/winning-a-user-experience-debate/

Slide 26

Slide 26 text

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?

Slide 27

Slide 27 text

1. Make sure everyone understands the problem Collaborative software development

Slide 28

Slide 28 text

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 “

Slide 29

Slide 29 text

2. Empower teams to do great work Collaborative software development

Slide 30

Slide 30 text

Maker

Slide 31

Slide 31 text

Manager

Slide 32

Slide 32 text

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 “

Slide 33

Slide 33 text

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)

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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)

Slide 36

Slide 36 text

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 “

Slide 37

Slide 37 text

Collaborative software development A final note on developers Resource Person ≠

Slide 38

Slide 38 text

3. Create a better design and development cycle (or, everyone gets a voice) Collaborative software development

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Collaborative software development The goal: Right-fidelity specifications

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

Collaborative software development Nothing is what happens when everyone has to agree. - Seth Godin “

Slide 44

Slide 44 text

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):

Slide 45

Slide 45 text

The Product Manager is The Decider

Slide 46

Slide 46 text

To deliver measurable business results through product solutions that meet both market needs and company goals.

Slide 47

Slide 47 text

Product Planning Product Marketing Strategic Product Management

Slide 48

Slide 48 text

Collaborative software development Product Manager Developer Visual Designer UX Research Interaction Designer Content Strategist Developers

Slide 49

Slide 49 text

4. Document thoroughly Communicate widely Collaborative software development

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

Publish everywhere, invite anyone

Slide 53

Slide 53 text

5. Prove that it works Collaborative software development

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Collaborative software development

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

Rian van der Merwe twitter: @RianVDM web: elezea.com Breaking down silos Building better software through collaboration