Innovation is not a Linear Phenomenon: The Faraday FF Zero 1 Example

Innovation ‘R’ Us

Every company is trying to “innovate” these days… no matter how large or small. Some of the bigger ones are virtually pleading with their multinational workforce through challenges, awards and incentives to come up with the magic pill that will help the company sail through stormy waters (As Alf Rehn summarized it [1], “in April we innovate, in May we fire people”) .

The smaller ones… well, there are companies based entirely on nothing else but “an innovative solution” to do something you could already do before (but this time in a Javascript framework). Looking at it from the Lean Startup perspective, I find it a bit weak when a whole business is based on the USP of “innovative”. Your solution could be based on quality attributes [2] that make it faster, scalable, interoperable, customizable, streamlined, or really 100 other ways that could maximize value… the means to achieve these better be innovative, because that’s the very least your customer expects from you!

Have you ever heard a Formula 1 driver call himself fast? Or a firefighter call him/herself brave? Or a surgeon boast about how precise she is? No, because these are attributes that are inherently expected of them. If they weren’t fast or brave or precise, they wouldn’t last very long in their line of work. Similarly, today all technology companies are expected to be innovative in order to survive. You know who boosts their own ego publicly? Pop stars:

 

Innovation is… Not Where You Think it is

Now, about Faraday. Earlier this year at CES I picked up this leaflet from the Faraday FF Zero 1 booth. Since then, I have thought often of the part marked in red below:

Faraday-3

“SVP of R&D … spotted a drawing of a racecar on a designer’s desk and thought …”

BOOM. Innovation happened. Did the designer have a mandate to come up with a supercar? No. Was the SVP in an in offsite innovation workshop, brainstorming with other employees? No. Was there an innovation competition or challenge going on in the company, with an award at the end of it? Probably not. This is possibly the best example that innovation does not happen in an institutionalized manner. When successful innovation happens, it comes from the most unexpected places, more often than not driven by synergy, and it opens up a non-linear value proposition:

innovation_graph2

Original image credit: [3]

 

An Indicator of Innovation

These days some people are solving more problems with a Raspberry Pi over a weekend, than during a whole week of work in front of a corporate laptop. What can leaders do to harness this immense creative potential? I think the answer is to build an organization conducive to innovation, geared up to quickly change course when an innovation potential appears on the horizon, and… basically get out of the way. Easier said than done, you say… there are risks, budgets, stakeholders, possibly even (shudder) committees… no way this is going to work.

Which brings me to the final point: how deeply is trust rooted in the company’s culture? In Faraday’s example, the SVP trusted that something produced by one of his designers was potentially a big deal. It did not come up through a chain of committees and approvals. It happened through synergy. And while structure can stifle synergy, trust can help it thrive.

I therefore argue that the amount of trust in a company is a solid indicator of innovation potential. How much employees trust the leadership’s direction, how much coworkers trust each other (even across borders and timezones) and how much the leadership believes in the people they hired: these factors determine how likely synergistic events will be recognized, and nurtured into products or solutions that are called “innovative” by customers and competition, not just by the companies themselves.


[1] Alf Rehn, “How to Save Innovation From Itself”. Craft Conf 2016 talk.

[2] George Fairbanks, “Just Enough Software Architecture: A Risk-Driven Approach”. InfoQ interview and excerpt.

[3] MintViz.

Advertisements

CES 2016: From the Fringes

The Consumer Electronics Show in Las Vegas is the premier trade show for tech product previews and release announcements, going as far back as the VCR in 1970 to Driverless Cars in 2013*. This year the CES featured about 3800 exhibitors, spanning 2.47 million sq. ft. spread out over 3 locations** visited by 170,000 media and industry professionals — and I was privileged to count myself amongst them. Featuring keynote addresses from Intel, Netflix, IBM, Samsung, nVidia, Volkswagen and other big names, a lot has been written, presented and shared on mainstream as well as social media about the 4 day event. This chart sums it up the hype pretty well:

Source: BuzzRadar.com

Source: BuzzRadar, CTA

I decided to share some of my views from the fringes, rather than the trenches — there is no point in rinsing and repeating what is already out there, nor do I have any delusions about the value of my personal opinion about tech that enables your car to count how many oranges are left in your fridge (yes, it was demoed, with voice control).

Oculus_c

The Oculus Rift demo was by far the hardest to get into — there was a line, a line to get in the line, and a third holding area. Eventually I made it on the last day, and it took me about 20 min to recover from the simulator sickness caused by piloting EVE Valkyrie’s spacecraft from a living room chair. I still felt there were rough edges and the HTC Vive was by far a more refined, immersive and truly flawless experience. The new Sony PlayStation 4 VR was quite impressive as well: I could lean out of a moving car and look behind me, and the granularity of control was so good I could rotate knobs on the car stereo. OSVR.org based devices were quite popular too, and some others that caught my eye were Virtuix Omni active VR platform, AntVR’s Holodeck concept and ICAROS‘ EUR 10,000 gym equipment that lets you fly around in a virtual world powered by your own body. Certainly beats playing first person shooters wearing VR googles on a treadmill, or riding a virtual horse on a exercycle.

There were tons of clones (mostly based on Gear VR) and drones. Augmented Reality seems to be gaining ground, but despite solutions like the Sony SmartEyeglass and Daqri Smart Helmet, VR seems to be more popular of the two. It’s worth noting that virtually every VR or AR demo was running on Unity3D content, including those at NASA and IEEE’s booths.

I also tried my hand at racing simulators of various scales: from small VR setups, to actual cars mounted on motion platforms, to a massive 4×4 grid of 55″ OLEDs in front of a force feedback seat rig. There were several interesting display technologies on show: 3D without glasses, transparent (scaling up to entire walls), curved and Samsung’s modular, edge-blending display tech straight out of a sci-fi movie. Avegant’s Glyph might turn the display industry on it’s head, though, much like the way it’s worn.

SamsungModular_c

 

On the automotive side, voice, gesture and intent based user interfaces seem to be gaining ground. Also making an appearance were adaptive user interfaces and improvements in sensor fusion, self-learning and self-driving techniques. There were tons of wearables, 3D printing and home automation booths. The two core themes seemed to be a maturing of the ecosystem (just about everything built on top of something else, not too many technologies solving problems from scratch) and apps for doing things that don’t need apps, like locking your front door. You’d think we would stop there, but no:

On the social innovation side, I found GrandPad, Casio’s 2.5D printing and the Genworth R70i Aging Experience very thoughtful. Besides these, I liked Mixfader‘s idea of an MVP slider for mobile DJs: after all, the crossfader is the main thing that requires precise tactile control, everything else can be relegated to the screen. Also impressive was Sony’s line of 409,600 ISO see-completely-in-the-dark cameras. And this is now a thing:

LifeSpaceUX_c

You’d also probably be able to find a lot of beautiful photos of Las Vegas on the Internet, so let me leave you with this video of a not-so-common Las Vegas activity that I squeezed in on the last day, courtesy of DreamRacing.com (very fringe-y because I picked a Nissan over a Ferrari). Thanks for reading!

* Apple, Google and Microsoft have their own tech events and despite the Xbox (2001) and Android devices (2010) being unveiled at CES, these companies tend to keep their product announcements exclusive to their own events. So no Hololens at CES.

** „Tech East (Las Vegas Convention Center), Tech West (Sands/Expo at the Venetian,  The Palazzo, Wynn and Encore) and Tech South (Aria and Vdara)

Amuse UX Conference, Budapest

Last week, I had the privilege of being part of a group attending the first edition of AmuseConf on behalf of our company. Amuse is “an international conference for anyone interested in how to design and develop successful products that users love”. It’s organized by the same good folks that bring us the outstanding CraftConf year after year, sponsored primarily by Prezi and UStream (and SAP in case of Amuse). They did a near-perfect job, with only minor glitches with the seating and catering on the first day. Considering that the Big Data oriented CrunchConf was also literally next door, the event was practically flawless. Fast, uninterrupted WiFi and no food options for vegetarians/vegans remained a hallmark this organizing team (even though Tom Illmensee, event MC is himself vegetarian 😉 ).

(BTW, if you’re wondering why so many tech conferences are being hosted in Budapest, the event’s WiFi password should give you a hint):

20151103_083708867_iOS

510 attendees from 32 countries (as far away as Australia) made Amuse a roaring success, as did its impressive lineup of Speakers27% of the speakers were women, which is great for a tech conference — I hope next year we have even more!

Below is a summary of the talks I found the most relevant to my work. But by no means does that mean you should skip the other talks… depending on where you are and what you’re doing, you might be interested in some of the eclectic topics covered such as:

  • Designing web interfaces for children by Trine Falbe
  • Conducting research outside “sample of convenience” by Bill Selman from Mozilla Foundation
  • Design Thinking by Tobias Haug of SAP (my favorite quote: “Innovation = Execution x Creativity”)
  • How to get your dream UX job by Andrew Doherty of Google (worth checking out just for his mad presentation skills)
  • The Ethical Designer by Cennydd Bowles
  • Storytelling in a multidevice landscape by Anna Dahlstrom

Design Equilibrium

By Jonathan Lupo

Jonathan opened the conference with a very engaging talk drawing parallels between businesses and ecosystems: a “balanced exchange of value between Actors, Enterprise and Brand”. He gave practical examples citing the application of Lynn Shostack’s work on Service Blueprinting to a transformation in the healthcare industry. I strongly encourage viewing his inspiring talk on YouTube.

His core suggestion is a separation of Product Design from Service Design. The latter “fills in whitespaces between points of [rich] engagement provided by products”, helping to restore balance to the overall experience, and hence the business ecosystem. This is the real intangible value of services, as opposed to products.

He also proposed the concept of an “Engagement Model”: a framework to contextualize all the data a business collects.

UX: Design as a Science

By Joel Marsh, author of the UX Crash Course

Joel’s key message was that “Scientific UX Design is reproducible”: essentially drawing on the principles of the Lean Startup and applying them to the UX domain. His presentation was one of the most popular and engaging ones, and his quotes and examples garnered a lot tons of positive feedback. One thing that struck me was his exposition on the two types of creativity: Creative expression and creative problem solving. He noted that an over-applicability of creative expression can make you feel good as a designer, but result in an over-designed and bloated product:

ArtVsDesign

Another talk I would highly recommend watching when it comes out on UStream.tv.

Making Dog Food a Part of Your Balanced Diet

By Toby Sterrett

Toby used his work at Simple Bank to highlight the pros and cons of “eating your own dogfood”. The initial employees used the app themselves, and one of the downsides was that the missed revelation that users of such a smooth app had to deal with a paper form-based process to close their account, which took up to 20 days.

Another inspiring talk that you should definitely check out, full of quotes of wisdom like:

  • “Delight is design’s superpower”
  • A past discussion on Leadership strategy: “Build a shared vision, get the **** out of the way”
  • “UX is not about throwing technology at a problem, but throwing people at a problem”

On the other hand, Simple A/B tested as many as 16 variations of their login page (for more examples, check out UserOnboard.com).

Live posters being created by @remarker_eu

Live posters being created by @remarker_eu

How We Built Hotjar and Onboarded 50k Users in a Year

By Dr. David Darmanin

David used practical examples from Hotjar to support his model of “Drivers, Barriers and Hooks” when dealing with site visitors. He also put a quirky twist on some timeless wisdom:

The two most amazing insights for me were:

  • Hotjar captures every single customer interaction on a Trello board, and uses that feedback to prioritize their features.
    • They also make their roadmap public, which demonstrates their commitment and at the same time reduces enquiries about feature requests
  • They use the income from their paid customers to fund the creative freedom to build features for their free customers

The Invisible Interface: Designing the Screenless Experience

By Avi Itzkovich

Avi, founder of UXSalon, opened with a discourse on recent editions of Microsoft Productivity Future Vision. From there he led the discussion on towards a future without bigger and wider screens (which wouldn’t require “superhuman arm strength”):

  • “The most profound technologies are the ones that become invisible” 
    • Like automatically opening sliding doors
  • “Voice UI is the future”
  • “Gesture control is here to stay, but not on screens”

The Best Interface is No Interface

By Golden Krishna

Golden surmised that we are all “chipping away at digital chores”, and we don’t have to be “slaves to screens”. He has laid the foundations of the #NoUI movement with his book“The Best Interface is No Interface”. His excellent talk (slides here) was supported by book reading and real examples. Also, don’t forget to check out his accompanying toolkit on “how to create elegant solutions with no screens”.

For further inspiration to join the movement,  take a look at his Producthunt collection of “interfaces that require little or no time with screens”.

Magical UX and the Internet of Things

By Josh Clark

Josh opened with an announcement of his book release: “Designing for Touch”. His presentation was literally magical, complete with a wand, to the point that he managed to tie in together excerpts from preceding talks and put the whole conference in perspective. I found a similar slidedeck from one of his previous talks here, and I highly recommend taking a look at it while we wait for the official conference videos to come up on Ustream.tv. It was a treasure trove of out-of-the box examples like:

  •  Augmented REality Sandtable (ARES), which literally turns dirt into a high-tech, military-grade user interface… using not much more than a Kinect and projector
  • Grab Magic, which brings superpowers to data transfer
  • Propeller Health, which connects Asthma inhalers to phones for health monitoring

Josh’s key message was “interaction at the point of inspiration”: that we should think of “the whole world is an interface, just like it has always been”. He proposed “thereables” instead of wearables: bits of smart technology in the physical space where we would expect to interact with them, not something we burden ourselves by carrying or wearing all day long. To this end, he suggested that “the smartphone is Magic Wand 1.0 for everyone” and we should start thinking of it as just more than a screen.

IMG_4185

Regarding user interfaces, he had 3 bits of advice that I found remarkable:

  • “Technology should amplify our humanity”
  • “We shouldn’t educate users on how technology works, unless we really *have* to”
  • “Honor intention, don’t assume it”

Josh ended with a call to action:

Like this one.

 

 

 

 

 

Evangelizing Lean Product Development

I’ve written and tweeted before about how influential I think Eric Ries’ The Lean Startup has been for me. While we wait for Eric’s next book, The Startup Waywhich is more focused on bringing lean thinking to big companies (and by the way is being researched in a very interesting way — read about it on KickStarter), the timing was right for me to assimilate my thoughts and share them with a group of colleagues.

Lean Prezi pub

While I’m still waiting for the feedback to pour in for my 3-part course, I’m very happy to have had the opportunity to share with others that “Lean” is not just some black art practiced in car manufacturing plants, and “Entrepreneurship” can take root even in large, established organizations. Now, more than ever, we are all living (and trying to thrive) in “conditions of extreme uncertainty”.

I hope I have been able to get across some of the thinking behind the concepts covered in Eric’s book: the Build-Measure-Learn feedback loop, the Minimum Viable Product, Innovation Accounting, Vanity Metrics, practical techniques like Cohort Analysis & Five Whys and finally the most relevant: The Innovation Sandbox.

I also threw in a bit of George Fairbanks’ Just Enough Software Architecturewhich addresses “engineering risk”, as opposed to “project management risk”. And of course, lessons learned from my enlightening weekend at Lean Startup Machine a couple of years ago.

The coming days will tell if the course was useful and comprehensible enough for others to practically apply some of the principles to their projects. I hope that over time we can build a community of like-minded lean practitioners within the organization, acting as enablers of sustainable innovation. #WasteNot.

Scrum, Kanban, Scrumban or Just Ban Scrum? (Part 2 of 2)

Part II: Some Solutions

Continued from Part 1, with the same disclaimer applied.

frAgile

 

Collaboration and Distributed Scrum

If you’ve been in a successful Scrum Team with geographically distributed members, I would really like to hear from you, O Venerable Master. After all, team effectiveness has been known to diminish with as much as 2 meters of physical separation. If you must do Distributed Scrum (hopefully as a transitory step), then here are a few tips that will (I hope) save you the trouble of learning the hard way:

  1. Obviously, ensure everyone on the team is fully aware of language and cultural differences, especially the Power Distance Index (if that sounds familiar, it’s from Malcolm Gladwell’s Outliers)
  2. Email is only 14-17% effective as a medium of communication (Videoconferencing helps)
  3. Further, information is lost exponentially as a function of distance and overhead of tools used (simply put, people are inherently lazy…)
  4. …Which may prevent you from achieving fully cross-functional teams without specialists
  5. Agile at scale requires trust at scale
  6. Everyone needs to have access to the same infrastructure (at the same latency) and an identical development environment
  7. Get Agile Evangelists (SM, Coaches, stakeholders) at every location and get them to agree on your organization’s Scrum process
  8. Eliminate mixed signals, possibly by having a Proxy Product Owner
  9. Empowerment and Autonomy are useless without Feedback
  10. Establish an Exchange Program where [at least some] developers from different locations get to experience the reality of their counterparts (This will probably be your best investment)

The most important consideration, given all the specific limitations of your situation, must be that whatever arrangement you come up with, is sustainable. Create success stories and replicate the model. And note that Distributed Team can very well exist without Distributed Scrum.

Why Are You Doing Scrum, Anyway?

One day I’m going to be an Anti-Agile Coach. Because I’m convinced they’re so many people getting it wrong, that there’s a lot of money to be made from it. But first, some free advice: You should really consider if Agile or Scrum is really applicable to your Organization, Industry and Business Context. A good starting point is the following thought process:

You would like to adopt Scrum (or Agile) because…

  1. …Your scope/specifications/customer commitments change often (If not, you might be indulging in WaterScrumFall)
  2. …Your market changes often, requiring quick adaptability (e.g. Competition pops up out of nowhere overnight)
  3. …You need to deliver (or release) continuously (As opposed to a one-time deployment, followed by maintenance)
  4. …Your technology stack can/will change often (i.e. you haven’t invested tons of $ in license fees, and/or you will evaluate multiple options)
  5. …You have the flexibility to experiment/take risks, and your organization rewards failure (or at the very least, doesn’t penalize it)
  6. …Your dev team is nascent, so you expect dev processes to evolve
  7. …Your industry is neither mission-critical nor heavily regulated (although there are exceptions as Nancy Van Schooenderwoert explains)
  8. …You have metrics to show that Scrum would be more effective
  9. …Your Admin/HR/IT teams have Daily Standups (yes, I have seen them happen)
  10. …Everyone else is doing it

If you scored low on the above checklist, please consider that Iterative Software Development is still a thing, especially if you’re dealing with hardware or manufacturing. It’s not Waterfall, but it’s Scrum with a bit more commitment.

On the other hand, you might be in a field of work where you’re ready to treat software development more like Surgery than Civil Engineering (as Dan North explains in his talk).

Whatever you do, don’t indulge in Reverse Waterfall: Convincing yourselves that what you delivered is in fact what you intended to deliver.

(Please share your thoughts and experiences as a comment or connect with me on Twitter: @survivalcrziest)

 

Scrum, Kanban, Scrumban or Just Ban Scrum? (Part 1 of 2)

Part I: Some Problems

I have been playing the Scrum Master role off and on since 2008, almost all of it for geographically distributed teams. During this period, I have been lucky enough to work for 3 different companies in 4 countries. Over the years, a sinking feeling has been growing within me that we have started using “Agility” to mask unwillingness (or I dare say, often, inability) to commit. Allow me to crystallize some of the thoughts that are forming in my head.

(My usual disclaimer applies: none of the below is intended to reflect on my employer(s) or specific colleagues, whether past or present. These are my personal, generalized opinions intended for retrospection.)

ScrumTF

Ceremonies and Metrics

First and foremost, if you don’t have Sprint Retrospectives, or in your organizational/business context, are unable to enforce accountability for, or effectively followup on, action items identified in the Retrospective, then read no further. Your Scrum is Doomed.

Sprint iteration size matters, too: “A 2-week sprint is just enough time for a mini-waterfall, and thus we are all basically whitewater rafting all the time” ( — Dan North).

If:

  • you’re not collecting metrics (at the very least: Capacity, Velocity, Committed vs Completed Story Points, Release Burn Up, possibly correlation between Story Points and Hours, if you’re organization is into that sort of thing, and various forms of Lead Time)
  • or not really paying attention to what they’re telling you
  • and they are not visible to and understood by the whole team

then you have already failed, you just can’t see it yet.

Demo vs Release

On the other end of the spectrum, when the mandate for Scrum or Agile comes top-down, often there is excessive emphasis on ceremonies. Specifically, the end-goal of the Sprint becomes the Demo, rather than the Release. Scrum clearly dictates that no additional or specific effort must be spent on the Demo, it should be more like a natural outcome.

You can have as many Demos as you want, but what really matters for a product is Customer Feedback. Which, just to be clear, is not the same as Internal Management Feedback. Management is inherently biased in favor of your team, after all they very likely played a big part in hiring and building it. 10 internal demos are worth a single demo in front of a potentially paying customer.

The focus, then, should be on the Release of the Potentially Shippable Product Increment (complete with changelog, user documentation, installers, troubleshooting guides and quality reports) rather than an orchestrated demo in a controlled environment. This is where Continuous Integration, Continuous Deployment and more recently, DevOps comes in to the picture. If your Release Process is time consuming, unpredictable, not automated and/or has too many dependencies that are not in your control, your team is not yet Agile.

Dependencies

If your software dev team is Agile, but the rest of the organization is not, Agile is going to fail. By rest of the organization, I mean other dev teams that they have dependencies on, manufacturing, HR, Admin, IT — every single department in the organization needs to understand, live and breathe Agile. Because if they can’t respond to change effectively, then they will hold your software dev team back.

The most effective way of crippling a self-organizing Agile team is to give them full accountability, with limited or no influence over those responsible for potential impediments.

Another assured path to mayhem is when multiple teams work on a shared codebase in concurrent sprints, or when a dependency is being iterated on in the same sprint as a feature that needs to be delivered.

The Bottomless Backlog

Often in geographically distributed teams, and/or on large scale projects, the physical Scrum Task Board is replaced by a more practical virtual one. Such task boards, like those provided by JIRA Agile, Rally, Trello and several others, replace Post-Its by virtual cards, enhanced by features such as attachments, comments, time tracking and reporting. Just like any other application of technology, there is a flip side: It just a matter of a few clicks and keystrokes to add something to your Product Backlog, or to alter project plans in a significant way by moving tasks around. It’s very easy to get carried away, and often we start injecting scope creep into the Backlog, disguised as finer details of existing features (for example see User Stories vs The User’s Story).

If your organization uses different tools for Requirements Management and Project Tracking, and if there’s no strict mapping from requirements to user stories (yes, it happens 🙂 ), then it becomes very easy to lose control of the project without realizing it. A more typical scenario is working with a limited budget (usually allocated upfront),  but adding tasks endlessly — kind of like a fractal with fixed surface area, but infinite perimeter. Even with regular Backlog Grooming and prioritization, your team will still feel dissatisfied because a major chunk of the Product Backlog will end up remaining undelivered.

Finally, if you’re not in a position where you can compromise features over quality, then your Agility is severely limited.

Upfront Architecture and Specification

Probably the biggest excuse we use Agile for is to do away with high-level architecture altogether. Different Sprint teams work on different areas of the project, each optimizing locally and focused on the immediate Sprint (or two). Eventually it becomes apparent that several teams have been solving the same problem, maybe (surprise) even in different ways. The Scrum of Scrums can help, but on the rare occasions when it does happen, it is more focused on execution than design. Towards the end, more incompatibilities surface and there is a rush to “adapt the Architecture to the Business Reality”, which is basically an update of the Architectural artifacts based on the code being delivered, rather than the other way round.

So let’s recap:

  1. Being Agile does not mean no design, it means less upfront design.
  2. There needs to be traceability from Requirements to Specification to Architecture to Design to Execution to Validation to Deployment. It doesn’t matter what you call these things in the context of your Industry, but just because you aren’t doing Waterfall doesn’t mean you can decouple execution from specification.
  3. Technical Delegation is not the same as Management Delegation. If you ask 5 teams to report progress using a specific tool, they will all report it the same way. But if you ask 5 self-organizing Scrum Teams to architect a technical solution, you will get at least 3 different results, if not 5 (or 7 with secondary recommendations).

Read on for some recommended solutions. I would love to hear your thoughts and experiences, please leave a comment or connect with me on Twitter: @survivalcrziest

Craft Conf 2015, Day 3

Continued from Day 2, here is a summary of talks I attended on Day 3:

From the Monolith to Microservices: Lessons from Google and eBay

By Randy Shoup | Video | Slides

Another eye-opening presentation with valuable insights, such as the fact that [a big organization like Google] doesn’t need architects, it just needs standardized communication and standardized interfaces. And that one of the biggest mistakes people make with microservices is reflecting the provider’s model instead of the consumer’s model. I highly recommend his talk, because it is based on the analysis of several Silicon Valley giants, successful either in the past or the present.

Interaction Driven Design

By Sandro Mancuso | Video | Slides

Sandro’s presentation was full of real examples rather than just theory. I had never heard of the Walking Skeleton before. It was an interesting intersection of DDD (Domain Driven Design), MVC-type architectures and SOLID principles, leading up to a pragmatic way of structuring and packaging software projects. Other advice from Sandro included modeling behavior, not state and not necessarily representing repositories as first-class citizens.

WebSocket for the Real-Time Web and the Internet of Things

By Peter Moskovits | Video | Slides

Not only was it an amazing presentation with live demos, Peter was also fully prepared with a backup plan for everything – including a PDF version of his presentation. After a historical perspective & technical explanation of how WebSockets work, he jumped into Kaazing demos which you can also experience online here. The most interesting was a kind of MVP for disseminating airline telemetry data (here).

Why Is An API Like a Puppy?

By Ade Oshineye | Video | Slides

RESTful APIs are not the solution to all of the world’s problems: Ade was short, succinct and insightful. The title of his talk reflected the fact that an API is an expensive long term commitment, it’s not just about the initial cost of software development. He got a lot of attention when he revealed that Google’s most successful API is AdWords, and it’s SOAP, not REST. Although REST is theoretically good, it doesn’t usually fit well with the real world consumer’s way of thinking. Another one of his gems was that if your [public] API is not being spammed/abused, then either no one is using it, or it’s happening and you’re not aware of it.

Implementing the Saga Pattern

By Caitie McCaffrey | Video | Slides

There wasn’t anything interesting to me during this time slot, so I decided to go with this one just for the Halo reference. There was just one picture of Halo. And a lot of “so” and “like”.

Techniques and Tools For a Coherent Discussion About Performance in Complex Architectures

By Theo Schlossnagle | Video | Slides

Theo decided it would be a good idea to plaster all his slides with huge pictures of steak. Anyway, after establishing that User Experience is measured in milliseconds, and that performance is also about the time spent between service layers, he covered distributed tracing systems such as Dapper and Zipkin.

IMG_3480

Great Engineering, Failed Product

By Marty Cagan | Video | Slides

Marty drew on decades of experience in Silicon Valley to summarize why great products and companies fail over and over again. I highly recommend watching his inspiring and insightful talk. Some of the things he touched upon while comparing successful and poorly performing teams:

  • Customers and company executives are a bad source of product ideas, because they don’t know what’s technically achievable
  • Developers are a good source, and so is Data (analytics, metrics, usage)
  • Multi-billion dollar projects are not based on a Business Case accurately predicting future revenue
  • Roadmaps are not a good indicator because Customers have other options available to them
  • Think Time to Money, not Time to Market – which means more than one iteration is involved
  • Product Managers are not mere [user] story writers – they need to have a deep understanding of the business, industry, customers and constraints
  • Most teams work in a way that gives them probably 20% of the benefit of Agile Methodologies
  • Value outcomes over output; think in terms of results, not projects
  • Successful teams run as many as 20 MVP experiments in a week – even if it involves hardware
  • Successful companies use an OKR approach to measure progress
  • The four product development questions:
    1. Will the customers choose it? (Customer Validation)
    2. Will they be able to use it? (User Experience)
    3. Can we build it? (Feasibility)
    4. Can our stakeholders support it? (e.g. Legality)

______________________________________________