Macro vs micro (slideshare)
24
Karl Adam Engineer & CTO @thekarladam Kalani Kordus Designer & CCO @kalkor Interaction Eleven • Feb 9-12, 2011 • Boulder, CO
description
With today's ever advancing technologies—better tools, frameworks, libraries— software/web development is becoming increasingly faster in many regards. Yet in large companies, the processes for designing, developing and deploying software/web products remains cumbersome. To a great extent, the processes have remained the same for nearly a decade, and are very slow. On the other hand, smaller companies (startups) are able to go from inception to deployment in very little time. They are able to iterate and experiment with new features sometimes on a daily basis. Can large companies learn from small company processes, and vice versa? Kalani Kordus and Karl Adam will juxtapose their large company (yahoo!), large team experience with their small company (smudgeproof), small team adventure. Their current design/development process—a mashup of traditional and progressive techniques—is akin to musical improvisation, Dirty Jobs and UFC cage fighting.
Transcript of Macro vs micro (slideshare)
Karl AdamEngineer & CTO@thekarladam
Kalani KordusDesigner & CCO
@kalkor
Interaction Eleven • Feb 9-12, 2011 • Boulder, CO
ENGINEERING
DESIGN
QUALITY ASSURANCE
ENGINEERING
DESIGN
QUALITY ASSURANCE
We will use Yahoo! Messenger for iPhone and Symposium as case studies to juxtapose a large company (Macro) software development process with our (Micro) software development process.
These projects were similar in scope. Yet, we were able to design and develop Symposium at a much faster rate.
ENGINEERING
DESIGN
QUALITY ASSURANCE
The Builders
ENGINEERING
DESIGN
QUALITY ASSURANCEEach builder reports to a manager who must approve at different stages of the process. They are similar to valves in a plumbing system; regulating the flow of things. Most of management are not builders anymore because their time is spent having formal meetings with other managers and executives.
ENGINEERING
DESIGN
QUALITY ASSURANCE
PRODUCT
RESEARCHINTERACTION DESIGN
VISUAL DESIGNPROTOTYPINGENGINEERING
QUALITY ASSURANCEPROJECT MANAGEMENT
MARKETINGPRODUCT
MARKETING
Product Managers are invited to all meetings. Marketing attends all milestone meetings; both act as additional valves to the process. Roles tend to be very specialized in large companies. In contrast, small companies are forced to wear more hats out of necessity.
PROCESS
PRD
ARCHITECTUREIMPLEMENT
TESTANALYZE
IDEATESKETCH
WIREFRAMEMOCKUPS
SPECIFICATIONS
DESIGN
IMPLEMENTTEST
ANALYZE
Beta/Triage
Alpha/Triage
ENGINEERING
= MILESTONES
PROCESS
TESTFIX BUGS
TEST
GM/Triage
Deploy
IMPLEMENTTEST
ANALYZE
Beta/Triage
ENGINEERING
BEERS!
= MILESTONES
REALITY
If something goes wrong, it requires going back through this rigid process to fix it. The farther an issue goes back in the process, the more valves it has to go through again. This process is very formal, and usually involves many meetings and stakeholder/management approvals to get the flow going again.
TESTFIX BUGS
TEST
GM/Triage
Deploy
PRD
ARCHITECTUREIMPLEMENT
TESTANALYZE
IDEATESKETCH
WIREFRAMEMOCKUPS
SPECIFICATIONS
DESIGN
IMPLEMENTTEST
ANALYZE
Beta/Triage
Alpha/Triage
ENGINEERING
TRAFFIC LIGHTS
vsROUNDABOUTS
http://www.ted.com/talks/gary_lauder_s_new_traffic_sign_take_turns.html
CONVERT
GM/Triage
Deploy
PRD
Beta/Triage
Alpha/Triage
CONVERT
This process could be improved by converting most of the traffic lights to roundabouts; metaphorically speaking. Less meetings, formalities and interruptions. This would improve the flow, and free up management to participate again as builders. Meetings would be minimal and informal because management would once again have a deeper understanding of how it all works on a technical level, resulting in a faster process.
GM/Triage
Deploy
PRD
Beta/Triage
Alpha/Triage
CONVERT CONVERT CONVERT
RECOMMENDATION
CONVERT
Managers Builders
PRODUCT
Product managers tend to have backgrounds in business (MBA), but amazingly do not have much –if any– experience with product design. Marty Cagan’s Inspired (How to Create Products Customers Love) explains what to look for in candidates when filling this role.
This role is crucial in the macro. They decide what gets built in what order, and are in charge of the overall strategy. This role is often over staffed and confused with project management. Having too many will surely slow down the process. Much like the starship enterprise, a product has the best chance of being nimble and insightful if there is just one captain. Like a CEO to a startup. They should curate the right team with the right dynamic, keep the ship straight and get out of the way.
CONVERT
One CaptainProduct Management
RECOMMENDATION
Our process is one huge roundabout. Design and Engineering are constantly influencing each other throughout our process. From the earliest ideation sessions, to the last line of code.
PROCESS
Concept to Creation, and everything in between. We flow like water. A constant continuum.
We begin by riffing on potential features during our initial brain dump. Over a period of time, the whiteboard sketches start to slowly gain more fidelity. Once there is a consensus on the core functions, the design moves toward full fidelity with pixel perfect mockups and animated examples of behavior.
SOFTWARE ARCHITECTURE
During this time the app logic is built. In the case of symposium, the server side backend as well.
SIGGRAPH 2010
When the final mockups are agreed upon, the front end development begins. Values (shadows, margins, sizes, text size, etc) and sliced PNGs are extracted from the PSD files.
INTERACTION ELEVEN
For the IxDA11 app, I (designer) was able to tweak the existing code to position items, change color values and swap images to match the IxDA11 brand. By wearing another hat, I was able to free up time for Karl (engineer) to work on more complex engineering tasks.
We often start our process in a linear fashion, but quickly find ourselves bouncing back and forth between roles. An idea can spark a series of code tests to validate if something is possible.
While conducting a competitive analysis, a marketing idea might come to mind.
Minor QA issues can circulate for days –even weeks– in a macro environment, because of their rigid formal process. If we run in to a QA issue, it is usually investigated, discussed and resolved within minutes.
Encourage adaptability by wearing more hats. Get dirty. Learn what your teammates really do by shadowing them for a day or two, or week. Meet your engineer or designer halfway; get a little more familiar with their tools. Teach each other.
Design and engineering should be involved from day one in the ideation process. It keeps engineering informed early on of what is expected of them later on, and it informs designers of technological possibilities. Yet, collaboration does not mean “Design by Democracy”. Rather, allow ideas to flow through the process –linear or not– and let your opinions regulate the rate.
Better software can be made faster if we have fewer formalities. Fewer captains, fewer meetings, means more work force to actually build your product. Captains, stay out of the way.
WEAR MORE HATS FEWER FORMALITIES
BE LIKE WATER
http://speakerrate.com/talks/5393-macro-vs-microfeedback for this session:
http://www.ted.com/talks/gary_lauder_s_new_traffic_sign_take_turns.html
TED (traffic stops):
@kalkor
@thekarladam
Links
http://vimeo.com/3841165Bruce Lee Interview:
http://www.amazon.com/Inspired-Create-Products-Customers-Love/dp/0981690408
Inspired (Book):
Gratitude
