Breaking down silos

My Tech4Africa 2011 talk on collaborative software development.

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