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?
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?
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
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
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
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
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?
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
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
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
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?
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 “
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 “
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)
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
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)
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 “
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
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
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
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):
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
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
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
rianvdm
muture
uxaustralia
root_recruit
ajstarks
koel
morganepeng
uxevents
aguringo
kazukikanda
dieckg
okazakityo
lara
jonrohan
3n
addyosmani
iamctodd
moore
nonsquared
sferik
jnunemaker
zenorocha
tmm1
keavy