The AgilityFeat blog

At AgilityFeat we are more than just designers and coders. We are also thought leaders. Our team has spoken at numerous conferences around the US, Europe, and Latin America. We are leading the way when it comes to applying agile methodologies to nearshore software development in Latin America. Our blog is where we share those lessons with you, as well as news about what our team is up to.

Authors
Arin cole David Ford
Categories
Startups User Group Reports conferences Customer Development lean Lean Startup Silicon Valley startups Agile Events agile agile2012 Continuous Deployment Startup News AskADeveloper BizDev Travels published scrum speaking UX Nearshore Agile Costa Rica nearshore AgilityCasts DareToBeLean boston news training webinar Lean Startup Conf ATDD product owner retrospective Projects ADP West CI TDD wishlisting Real Time real time Real Time Messaging webrtc testing Verify/ATI coaching big data hadoop hbase ruby ruby on rails HTML 5 NodeJS Real Time UX San Francisco fixed price education distributed estimation xp kanban Agile Richmond AgileCville body shops rapid feedback Standup Minimum Viable Product MVP Pivot Split Testing Startup leanDC marketing Lean DC ALNDC APLNDC remote standup games Philly Charlottesville Coding Across America mobile AgileDC points humor hours range XP2011 burndown Uncategorized LeanCville HereCostaRica rails railsconf entrepreneur Design design responsive web design mobile application tablet InnovateVirginia AgileIowa ACCUS StickyMinds TechWell product development product development QANews offshore Outsource lean startup machine outsource MoDevEast html5 Company Culture Pro Tips UVA entreprenuer database events usability
Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
Year
2014 2013 2012 2011 2010

HTML5DevConf Video: 6 Months with WebRTC

Posted By:

Last May I had the pleasure of presenting at the HTML5DevConf in San Francisco. With me was David Alfaro, AgilityFeat co-founder, and Mariana Lopez, our UX lead. Also joining us remotely was Allan Naranjo, a software engineer at AgilityFeat and th...

Arin Sime

HTML5DevConf Video: 6 Months with WebRTC

Last May I had the pleasure of presenting at the HTML5DevConf in San Francisco. With me was David Alfaro, AgilityFeat co-founder, and Mariana Lopez, our UX lead. Also joining us remotely was Allan Naranjo, a software engineer at AgilityFeat and the development brains behind the application we presented.

Our presentation focused on what we had learned during our first six months with WebRTC, during which we built a simple webinar tool based on WebRTC using the PubNub api for both publish/subscribe messaging in the app as well as WebRTC calls. We built this tool as an experiment on our part to become familiar with the technology, and used it as the basis for a talk that we took not only to San Francisco, but also Washington DC, Atlanta, North Carolina, Virginia, and New York City. We also used this webinar tool as the basis of our e-book on Building Real-Time applications with WebRTC.

The HTML5 conference has now posted the video of our talk online, so you can watch it below. We had a lot of great questions from the audience, and we really enjoyed the conversations it generated. One of the interesting conversations this lead to after our talk was about the value of hosted STUN/TURN servers for WebRTC, using a service like XirSys. We’ve been using XirSys on another WebRTC project since that time and we can definitely vouch for it’s value.

What other questions do you have that are not covered in our talk? Did this create any ideas for your business? I’d love to hear about them – please contact me at Arin@AgilityFeat.com.



Are you ready for the real-time web?

Our team has deep expertise in UX, design and development for the Real Time web.

Don't fall behind on the latest technologies! Sign up now for monthly updates from our blog and our RealTimeWeekly.com newsletter which has the best content from across the web on real-time development with frameworks like WebRTC and WebSockets.

Oh yeah, we have a book too!

Toying with a World Cup second screen experience

Posted By:

This is a very stressful month for me, because I’m trying to balance work, family time, and World Cup viewing time. As a fan of the United States and Costa Rica national teams, it’s also been a pretty wild World Cup to watch. Costa Ric...

Arin Sime

Toying with a World Cup second screen experience

This is a very stressful month for me, because I’m trying to balance work, family time, and World Cup viewing time. As a fan of the United States and Costa Rica national teams, it’s also been a pretty wild World Cup to watch.

JermaineJones

Costa Rica has advanced as I write this against all expectations with wins over Uruguay and Italy, and the USA still has a good chance of advancing even after the heartbreaking last minute goal by Portugal last night.

In order to combine work and the World Cup, I’ve been toying with ideas for a “2nd screen experience” application while watching soccer/football games. Last week I threw together a simple application to allow chat users to predict who will score the next goal. With a a few friends, we tested it out last night.

Here’s what the application looks like “in action”…

NextGoalBetaUse

You have a pretty standard chat room in a responsive design, and you can pick any screen name you want right now. This is a quick and dirty hack to test the concept, so there’s no authentication or anything fancy yet.

On the bottom of the screen are images of the complete rosters of the US and Portugal teams. Click on any of the players’ faces, and you will send a message to the chat room under your name announcing that you are predicting that player is about to score.

Screen Shot 2014-06-23 at 6.47.20 PM

When someone does score, you could just type in a message to that effect, or you could press the handy “GOOOAAAALLLL!!!” button that I added. Nothing fancy, but it works.

Screen Shot 2014-06-23 at 6.21.44 PM

We tested this app for a while in the US/Portugal match yesterday and learned a few quick lessons about the UX of the app that I’ll share later this week. For now, I’ll focus on the implementation details and the value of doing this type of quick and dirty Minimum Viable Product.

This app took about 6 hours of work total. The first thing I did was find a chat room example to start with. I chose this example from the PubNub blog. I picked this one for two reasons:

1) I am already familiar with how PubNub works and have an account with them, so I knew this would be easy to work with and the messaging infrastructure would scale well if I get a lot of unexpected traffic.

2) Their example uses the jquery mobile framework, and so I knew that I could hack on top of their example without involving any other design or UX talent from AgilityFeat. We have plenty of that talent, and if we continue with this app I’m sure that Mariana and Daniel will want to redesign it, but this allowed me to build it quickly over the course of a couple evenings without involving anyone else, and yet I still get a decent mobile experience (very important for a second screen experience since most people are watching the game with their tablet or phone in hand, not a laptop).

Here is what it looked like in the mobile view … you would need to scroll down more to see all the players (click on the image to see full size).

NextGoalMobileView

The pubnub example is just a straightforward chat room, which I then integrated into a bare bones NodeJS and Express app and deployed on Heroku.

The first coding I did was to hardcode in the player images that I found online from their team websites. Putting the images and player names in the code was actually the most time consuming part. I would definitely want to find an API or some other source for this information if I were trying to follow multiple soccer leagues over a full season, but hardcoding it was sufficient for me to get a simple MVP up and running to test the idea.

NextGoalPlayerViews

I used a non-existent CSS class definition on each player image, and then did a class selector to apply one event handler for clicking on any player’s name. When an image is clicked on and the event fired, all it does now is put a message in the chat room indicating the player you are predicting will win. My concept was that choosing players during the heat of the game would be easiest by looking at their faces, ideally with the player name and jersey number on the image too. This allowed me to test that idea during the flow of a real game (that I actually cared about) and see how I could do finding players in real-time.

Notice the class “playerPrediction” added to the player image below … this was added to all the images.

And here’s the OnClick event that is fired for all images with that class attached:

That’s basically it! You can see the source code up on GitHub if you like. To see the rest of the code for sending the chat messages with PubNub, check out the main javascript file. We’ll play with it during a couple more matches this week, but I can already imagine all the things I would want to do with this if we make it into a real 2nd Screen Experience or real-time dashboard application.

Would you like to try it out? You can see the app yourself in all its current crude-MVP glory here:

http://next-goal.agilityfeat.com/

For now, the most important thing to note is that through the existing PubNub example, a few code hacks, hardcoding player data, and my willingness to show an unpolished application to friends to solicit feedback, I have already learned a lot. For only an investment of a few hours of my time over a few evenings. Now that’s the right way to build your first Minimum Viable Product!



Are you ready for the real-time web?

Our team has deep expertise in UX, design and development for the Real Time web.

Don't fall behind on the latest technologies! Sign up now for monthly updates from our blog and our RealTimeWeekly.com newsletter which has the best content from across the web on real-time development with frameworks like WebRTC and WebSockets.

Oh yeah, we have a book too!

The 3 phases of MVP development

Posted By:

The other day I was speaking with a potential development customer when I realized two things: 1) He doesn’t need us … yet. 2) He can’t afford us … yet. “Yet” is a key addendum to both realizations. He has some interesting ideas, and a pretty well...

Arin Sime

The 3 phases of MVP development

The other day I was speaking with a potential development customer when I realized two things:

1) He doesn’t need us … yet.
2) He can’t afford us … yet.

“Yet” is a key addendum to both realizations. He has some interesting ideas, and a pretty well thought out MVP (Minimum Viable Product) scope definition. But those ideas haven’t survived contact with the customer yet, and the non-technical aspects of his business plan haven’t been proven yet.

As I explained the development options open to him, and how our team fits in, I described the following 3 phases of MVP development to him. Obviously, these don’t apply equally to all situations, but I’ve tried to describe a path that many entrepreneurs like him should follow.

#0 – Pre-development tasks

I would do you a major disservice if I didn’t remind you never to jump straight to development of an MVP. Especially if you’re a bootstrapping startup, you’ll get some hints below the development of an MVP is not cheap. Don’t waste that money, or more importantly your time, without first doing some customer development to understand what your customers care about.

You’ll never fully understand what your customers are willing to pay for until you build an MVP and put a price tag on it, but you can save a lot of time, money, and headaches by doing your customer research first. Then proceed to the following phases of MVP development.

#1 – The MVP templator

You probably have a pretty clear vision of how you want to build the first web application for your business. The excitement and creativity of that vision is what gets you out of bed in the morning. It’s extremely tempting to jump straight to the custom development, based on a desire to make the experience for customers perfect from day one.

Rein yourself in: The challenge here is that you probably don’t know as much as you think, and building a less expensive solution based on template solutions like Content Management Systems may be the right way to start. Or you might be able to build a “Concierge” solution that looks complete on the outside, but in reality requires manual processes behind the scenes to make things work. You won’t be able to implement your process or your design perfectly, but you may be able to cobble together a “50%” or concierge solution that will allow you to learn from your customers along the way.

Expected cost: $5000 – $25000 USD
Expected time: 2-8 weeks

Skip this step when: Prior business experience (not just gut feelings) tells you more definitively that you know what customers want. Or your system is heavily dependent on a specific technology that requires up front development before customers can understand your vision (Careful: Here be the dragons of self-deception).

Never skip this step when: You’re bootstrapping your business, unless you have enough of someone else’s money to risk on going straight to a custom solution.

Move beyond this phase when: It’s been a few months or a year, and that inexpensive templated solution is starting to constrain you. Customers keep asking you for certain features, but they aren’t feasible to implement in the template or concierge solution without a total hack. You did the hack anyways, and now you’re probably paying for it with some software maintenance nightmares.

#2 – The custom MVP

You’ve squeaked by with the concierge or template solution for a while. You’ve made a little money – congratulations! Or alternately, you’ve had enough success that you have brought on investors or partners who can fund the next stage of work.

Now it’s time to build the application that you really wanted. You might rebrand yourself to separate from any bad experiences in the first round or work. You will definitely change the product’s vision, design, UX, and functionality based on what you learned from those initial customers. This is the time to completely disrupt before you start promoting the product you really wanted.

You likely need a different breed of developer at this point, and you definitely need higher quality UX and design work. You’ll have to pay for it naturally.

Expected Cost: $25,000 – $100,000 USD
Expected Time: 2-6 months

#3 – Post-production MVP

The MVP was a big success – congratulations! You’ve got a product that generates steady revenue now. Hopefully you have enough to cover your expenses and draw a decent salary … or at least enough to bring that next round of investment on board.

Your focus is shifting now … you are worried about 3 things: Stability, Scalability, and Sustained Innovation. Your development iterations are mainly bug fixes and small feature changes, and you are releasing code to production at least every 2 weeks. You are paying more attention to analytics, and maybe doing A/B testing of features. You should continue to do customer interviews to understand what people like or dislike about your website.

Some of your developers may be starting to get slightly bored, and others will just be happy the big push is over and looking forward to more stable work. You can help keep them all engaged by making sure there is always innovation going on, not just “bug fixes”, and let them tackle some technical debt of their own choosing too.

This is a good point to start hiring more in house talent, and to put contract development teams on a longer-term retainer contract.

Expected Cost: Varies widely based on your needs, but you probably can expect an IT payroll from $35k-$50k USD per month for larger development teams, or a similar amount to a development company. Smaller applications that don’t require full time development attention might get by with monthly maintenance costs under $10,000 USD.
Expected Time: Forever – there’s always changes you’ll need to make to keep up with your competition and to squash bugs that crop up.

Your experience will vary

Naturally, the numbers and scenarios above are going to vary widely based on your business model, the scope and complexity of your technology needs, and dozens of other factors.

The transitions between these phases will not always be obvious. For our team at AgilityFeat, we excel at phase 2 – the design and development of the custom application. We also do very well at phase 3 – the ongoing support of the post-deployment MVP, although we prefer to be involved in ongoing innovation rather than pure maintenance work.

We may not be the ideal choice for Phase 1 (we aren’t in the case of this customer I was speaking with). That’s because we charge more than the types of companies that will customize a Content Management System for you, but we also bring much more value in terms of custom building a strong technical application with compelling UX and design. Sometimes we can help build a concierge-type solution for Phase 1 if a template solution just won’t do. We can also help out with Phase 0 and product research, although you as the entrepreneur have to stay heavily involved on that process.

When is the MVP done?

Short Answer: Never. While the actual software can and will change, the basic idea of delivering small chunks of value to your customers constantly should never change. In that sense, you will never truly move beyond the MVP phase.



Are you ready for the real-time web?

Our team has deep expertise in UX, design and development for the Real Time web.

Don't fall behind on the latest technologies! Sign up now for monthly updates from our blog and our RealTimeWeekly.com newsletter which has the best content from across the web on real-time development with frameworks like WebRTC and WebSockets.

Oh yeah, we have a book too!

Recording in Real Time with the Web Audio API (...

Posted By:

Building software to manipulate files is always tricky, however when we are talking about audio files and specifically about the Web Audio API in HTML5, this challenge gets significantly more difficult. In this post, we will look at the basics you...

Arin Sime

Recording in Real Time with the Web Audio API (Part 1)

Building software to manipulate files is always tricky, however when we are talking about audio files and specifically about the Web Audio API in HTML5, this challenge gets significantly more difficult. In this post, we will look at the basics you need to know to get started recording and manipulating audio in the browser with the Web Audio API.

Browser Compatibility

There are many things to take into consideration, starting with audio file and browser compatibility. Although browsers are getting more standardized, there are still syntax nuances for particular calls that you need to be aware of when using the Web Audio API. For example, here is the way to execute the call for GetUserMedia in Chrome, Android, Firefox and Internet Explorer (notice the difference in prefixes);

Also, there are differences between browser type in terms of the files types that each browser can play.

http://www.w3schools.com/tags/tag_audio.asp


Table Source: W3Schools.com

You will want to specify a base case or cases for the file types you want to enable. For our example we took a “democracy” approach which means using the audio format that is compatible with most browsers. We decided to use Wav files.

The first thing we do is check file type and if it is not supported, run a process to convert it to Wav. In order to determine whether or not a particular file type will  play, you can use the canPlayType method of audio and/or video objects:

Here’s the sample code:

And here is a list of common values for the canPlayType method:

Lastly, The possible return values from that call are:

So, when canPlayType returns an empty string, we convert the file.

Understanding the HTML5 Web Audio API

Before the HTML5 Web Audio API, we used the audio tag to interact with audio files, calling play, pause or stop.  Now the Web Audio API opens a whole new set of opportunities via audio context. An audio context controls the creation of the nodes it contains and the execution of the audio processing, or decoding.

Put more simply, the audio context let’s you manage sounds. In our example, we will create a single audio context for our application (more on that later).

A super important part of the HTML5 Web Audio API are the AudioNodes. AudioNodes are the basic units of AudioContext. The AudioNodes represent audio sources, the audio destination, and intermediate processing modules. We’ll talk more about AudioNodes in our next post.

Here is a list of the AudioNodes we used:

It’s worth noting that some browsers limit the quantity of AudioContext instances you can create so we are only creating a single AudioContext instance for our application.

When we are working with audio files we do not use the actual Wav file, we load the audiofile but get an arraybuffer. From there we can start manipulating the file.

Here’s how it works … We use the XMLHTTPRequest object to make a call to the file url we want to load, and that will give us access to the arraybuffer of that file:

As you can see in the snippet of code we are setting the responseType to ‘arraybuffer’. Other possible values of the responseType attribute are “blob”, “document”, “json”, and “text”. See here for more information on response types for the calls.

Audio quality is important and with the arraybuffer we can create a new audio file to be played that we can manipulate. We can set the quality of the audio by specifying the sample rate.

Sample rate is the number of samples of audio carried per second, measured in Hz or kHz (one kHz being 1 000 Hz). For example, 44 100 samples per second can be expressed as either 44 100 Hz, or 44.1 kHz. So, if you need to increase the quality of a sound, you can increase the sample rate.

However, it is also important to keep bandwidth in mind. If you are going to be uploading and downloading the files you might want to record at a lower sample rate like 20kHz (and use that as a source) to reduce the file size and CPU use.

In the example above, we use the arraybuffer coming from the XMLHTTPRequest (V2).

Once we have the arraybuffer, we create a blob. To create a new blob, the constructor needs a new instance of dataView and that’s created from the array buffer.

It is important to know that we use an instance of OfflineAudioContext object which is similar to the audioContext object. The difference is that the OfflineAudioContext will generate the audio content faster in a buffer.

At this point, you have laid the groundwork for recording and manipulating sound via the Web Audio API. In our next post in the series, we’ll dig into the final steps to take to complete the project.



Are you ready for the real-time web?

Our team has deep expertise in UX, design and development for the Real Time web.

Don't fall behind on the latest technologies! Sign up now for monthly updates from our blog and our RealTimeWeekly.com newsletter which has the best content from across the web on real-time development with frameworks like WebRTC and WebSockets.

Oh yeah, we have a book too!

Video: Mariana Lopez on Real-Time Interaction D...

Posted By:

Last week our UX lead Mariana Lopez presented at the ModevUX conference in Washington DC on how to do interaction design for Real-Time applications. Below is the video from her talk – check it out to learn some best practices for your next r...

Arin Sime

Video: Mariana Lopez on Real-Time Interaction Design

Last week our UX lead Mariana Lopez presented at the ModevUX conference in Washington DC on how to do interaction design for Real-Time applications. Below is the video from her talk – check it out to learn some best practices for your next real-time or WebRTC application.

Interaction Design for Real Time Applications – Mariana Lopez of AgilityFeat at ModevUX from Arin Sime on Vimeo.

If you would like a copy of the slides, see slideshare.

Here are Mariana’s key takeaways from the talk:

1. Don’t let the technology become more important than the experience.

Playing with cool new technologies can be a lot of fun, especially many of the cool real-time technologies that we like to play with here at AgilityFeat. But keep in mind that you are building something that should deliver value to users, not just illustrate cool technology.

2. Feedback is ALWAYS important

In a real-time app feedback is more critical than usual because users will be nervous about things like “is the app still connected? is the data fresh?”

3. Visual Hierarchy: Selecting when and how to show information.

Where you place data in a real-time application is crucial to its usability, or whether it just becomes a distraction.

4. Handling changes in a fast changing environment.

When changes occur, you need to let the customer know that data has been updated, but without disrupting their workflow of what they are trying to accomplish right now.

5. Identifying important micro-interactions

The little details here count a lot. Will a call be muted or un-muted by default? How will you make it easy for the user to know that?

6. Graceful degradation

If connection problems occur, the user needs to be made aware of that so that they don’t think the problem is on their end, or that the data source or person they are communicating with is not intentionally being non-responsive.

More on real-time applications

Mariana’s workshop at ModevUX was a lot of fun, but it was brief and really just touches on these design issues. If you’re interested in learning more about real-time applications, then you should check out our newsletter Real Time Weekly, and our book on Building Real Time Apps.

We are also happy to discuss your Real Time Application ideas with you – just contact Arin Sime at Arin@AgilityFeat.com, 434 996 5226, or setup a meeting at Arin’s soHelpful profile.



Are you ready for the real-time web?

Our team has deep expertise in UX, design and development for the Real Time web.

Don't fall behind on the latest technologies! Sign up now for monthly updates from our blog and our RealTimeWeekly.com newsletter which has the best content from across the web on real-time development with frameworks like WebRTC and WebSockets.

Oh yeah, we have a book too!

2 Quick examples of WebRTC in-context communica...

Posted By:

I believe the great promise of WebRTC based video, audio and data applications has nothing to do with browser compatibility or plugins. It all comes down to finding innovative ways that you can use these technologies to add value through in-contex...

Arin Sime

2 Quick examples of WebRTC in-context communications

I believe the great promise of WebRTC based video, audio and data applications has nothing to do with browser compatibility or plugins. It all comes down to finding innovative ways that you can use these technologies to add value through in-context communications.

Recently I came across two examples worth highlighting. The first is online education, and the other is for technical hiring.

Minerva using WebRTC to build an online University

I’m not just talking about online courses here, but an actual University founded on the idea of completely virtual education. Minerva’s overall model is fascinating, and you should check out their site. Particularly relevant to our conversation though is that their technology is built on WebRTC.

Minerva WebRTC Screen Shot

It’s not just about video chat though, far from it. This is what I mean by in-context real-time communications. The professor is doing a video chat with a large group of students, but they are also conducting polls through the same tool, manipulating data and images, and all of it is seamlessly integrated into one experience. I love how the data is being overlaid on top of the video in the Minerva demo.

By the way, it’s my understanding that Minerva is implementing WebRTC with the help of the open source Licode WebRTC platform.

HackerRank provides Remote Technical Hiring on a Real-Time platform with Twilio

TechCrunch recently highlighted a platform called HackerRank that helps you conduct remote technical interviews. The employer and interviewee are connected to an audio call using Twilio, and then the employer is able to watch the interviewee complete a coding exercise in real-time.

Hacker Rank codepair_audio_2

This might scare away some developers, but that’s probably a good thing. The value of this platform is that you get to watch a candidate code in real-time, and you can see how they solve problems and learn about their thought process. This addresses a huge risk in hiring developers, because those who interview well are not always those who code well, and vice versa.

How will you change the communication paradigm for your users?

Don’t be hindered by thinking of just how to add video chat to your application. The truly innovative and successful real-time apps are going to be the ones that focus on creative new ways to collaborate and add value to the conversation, not just add video.

To learn more about WebRTC and real-time technologies, we suggest our free newsletter RealTimeWeekly and our e-book on Building Real-Time Web Applications.



Are you ready for the real-time web?

Our team has deep expertise in UX, design and development for the Real Time web.

Don't fall behind on the latest technologies! Sign up now for monthly updates from our blog and our RealTimeWeekly.com newsletter which has the best content from across the web on real-time development with frameworks like WebRTC and WebSockets.

Oh yeah, we have a book too!

Real-Time Apps: Designing for the 4th Dimension

Posted By:

Today Mariana Lopez gave a talk at the ModevUX conference in Washington DC to a packed room on UX and design considerations when building real-time web applications. The slides are available below, and we have also posted the key takeaways below. ...

Arin Sime

Real-Time Apps: Designing for the 4th Dimension

Today Mariana Lopez gave a talk at the ModevUX conference in Washington DC to a packed room on UX and design considerations when building real-time web applications. The slides are available below, and we have also posted the key takeaways below.

Here are Mariana’s key takeaways from the talk:

1. Don’t let the technology become more important than the experience.

Playing with cool new technologies can be a lot of fun, especially many of the cool real-time technologies that we like to play with here at AgilityFeat. But keep in mind that you are building something that should deliver value to users, not just illustrate cool technology.

2. Feedback is ALWAYS important

In a real-time app feedback is more critical than usual because users will be nervous about things like “is the app still connected? is the data fresh?”

3. Visual Hierarchy: Selecting when and how to show information.

Where you place data in a real-time application is crucial to its usability, or whether it just becomes a distraction.

4. Handling changes in a fast changing environment.

When changes occur, you need to let the customer know that data has been updated, but without disrupting their workflow of what they are trying to accomplish right now.

5. Identifying important micro-interactions

The little details here count a lot. Will a call be muted or un-muted by default? How will you make it easy for the user to know that?

6. Graceful degradation

If connection problems occur, the user needs to be made aware of that so that they don’t think the problem is on their end, or that the data source or person they are communicating with is not intentionally being non-responsive.

More on real-time applications

This was just a super-quick summary of Mariana’s talk from the conference. If you’re interested in learning more about real-time applications, then you should check out our newsletter Real Time Weekly, and our book on Building Real Time Apps.

We are also happy to discuss your Real Time Application ideas with you – just contact Arin Sime at Arin@AgilityFeat.com, 434 996 5226, or setup a meeting at Arin’s soHelpful profile.



Are you ready for the real-time web?

Our team has deep expertise in UX, design and development for the Real Time web.

Don't fall behind on the latest technologies! Sign up now for monthly updates from our blog and our RealTimeWeekly.com newsletter which has the best content from across the web on real-time development with frameworks like WebRTC and WebSockets.

Oh yeah, we have a book too!

NYC WebRTC presentation

Posted By:

Back in April I had a lot of fun presenting on WebRTC at the New York City Node.js meetup. We met at the offices of Shutterstock in the Empire State Building, and I was the second of two presenters that evening. Despite the late hour, the group th...

Arin Sime

NYC WebRTC presentation

Back in April I had a lot of fun presenting on WebRTC at the New York City Node.js meetup. We met at the offices of Shutterstock in the Empire State Building, and I was the second of two presenters that evening. Despite the late hour, the group there asked a lot of great questions.

Hakka Labs was kind enough to record the presentation, and it’s posted on their site. You can also watch the YouTube video below.

This is also a good preview of a session that David Alfaro and I are leading this week at the HTML5DevConf in San Francisco. We’ll be presenting on “Six Months with WebRTC”, where we will use some of the material in the above presentation, but then also add in additional insights our team has had about designing and building WebRTC applications. It should be a fun session, so please join us!



Are you ready for the real-time web?

Our team has deep expertise in UX, design and development for the Real Time web.

Don't fall behind on the latest technologies! Sign up now for monthly updates from our blog and our RealTimeWeekly.com newsletter which has the best content from across the web on real-time development with frameworks like WebRTC and WebSockets.

Oh yeah, we have a book too!

4 ways Perfection is killing you

Posted By:

Whether you are a bleeding edge startup or a large corporation running agile teams, here are four ways that you may be abusing agile concepts and letting perfection kill your chances of success. Product Owner Perfection In an agile team, the Produ...

Arin Sime

4 ways Perfection is killing you

This is what angry customers might look like. Don't make them angry.Whether you are a bleeding edge startup or a large corporation running agile teams, here are four ways that you may be abusing agile concepts and letting perfection kill your chances of success.

Product Owner Perfection

In an agile team, the Product Owner (PO) is the “voice of the customer” to the development team.  They play an incredibly important role in the success of the project.  The PO will end up writing most of the user stories that describe the features the team will work on next, and equally important, the PO sets the priority of what to work on next.

Implicit in this prioritization duty is that the PO is also the person who says “go” and approves the deployment of new functionality to production.  So what happens when your product owner keeps saying “just do this one more thing and then we’ll deploy”? 

For a startup, this sort of “all or nothing” attitude will not just kill your project, it will destroy your business.  It will take you so long to satisfy that perfectionist Product Owner that you will end up missing your window of opportunity with customers.  Somebody else is going to build a less perfect version of your idea first, and they will win the customers before you even have a chance.

For a large company, Product Owner perfectionism is still bad.  It means that your schedules are going to slip, major initiatives will not be completed on time, and your agile team is going to look a lot like a very slow waterfall team.

Developer Perfection

Good developers are an essential part of a successful project, and so it’s easy to go overboard and hero-worship their technical prowess.  But sometimes that desire to be the best developer out there can kill your project.

Developers (in general) are very creative folk who take immense pride in their work.  The best ones also really enjoy playing around with the latest technologies and trying new things.  But even if you’re a non-technical leader, you can’t give them free reign or they will have so much fun building shiny objects that they will never get the project done on time.  I’m a developer by training … trust me on this.

Even if you can’t debate the details of technical decisions being made, you need to set clear boundaries for the team to work within.  If there is a fixed date you must have the functionality done by, communicate that from day one.  Make it clear that meeting that date is the most important thing, and you are willing to compromise on anything but that date.  The same is true for other project constraints such as budget or feature sets.  You can’t have everything, so pick one constraint at the beginning, and make it clear to the development team that is the constraint that must be met above all else.

If you’re project has no constraints (yeah right), then make one up.  You need to give the developers those guardrails.

Scrummaster Perfection

Are you agile enough?  I mean, are you truly Agile?  If you hear this a lot from your newly minted and Certified Scrummaster, then you are at risk of Scrummaster Perfection.

It doesn’t have to be agile methods like Scrum or Kanban, or even the Scrummaster as the culprit.  Perhaps we should just call this Process Perfection instead.

Any process should be judged by the results it produces.  Not the process results (aka documents and meeting rituals), but the actual value delivered to customers.  Are customers happier with us than they used to be?  Are they getting more value from us than in the past, and are we delivering that value more efficiently?  Than our process is working.  That’s all that matters.

It just so happens that agile methods tend to do the best job of delivering more customer delight more efficiently.  That’s why agile is popular.  But they can be abused and if you spend all your time worrying about adhering to some agile book you read, then you will not deliver much customer delight.

Please remind your Scrummaster and team that agile methods are not meant to be prescriptive – they are a set of guidelines and principles.  You can (and should) constantly change your process in order to better serve your customers.  As long as you are still adhering to the basic tenets of the agile manifesto, you can declare yourself agile.

From your customers’ perspective, they don’t even need to know you’re agile.  They don’t give a rip.  You should just be doing a better job for them than you used to.

Quality Perfection

I’ve already complained about perfectionism from our product owners, developers, and scrummasters, so who’s left for me to alienate?  I know, let’s pick on testers for a moment!

I am all for testing, both manual and automated.  I am also all for high quality software.  I hate it when a bug keeps me from doing something important on another company’s web site, so why should I accept anything less on my own?

The thing is … all bugs are not created equal. If I can’t accomplish core web site functionality on the most commonly used browsers, then yes, that bug has to be dealt with quickly and should be caught before it’s deployed to production.

But should bugs in older browsers keep you from deploying software now?  It depends on your customer base, but probably not.  You can probably live without a fully functional site in IE 8.  Or you can change the code for that browser to be simpler and not have as rich functionality.

If the bug is in an obscure part of your administration console that very few users notice, then maybe it doesn’t need to be dealt with right now.

The point is, many testers have a problem with perfectionism.  I find this to be particularly true with testers in large companies because in the past they were judged by the wrong metrics.

A tester should not be judged by how many bugs escaped the test environment and made it to production.  A tester should be judged the same way as the whole team – are we making our customers happy by getting them the right features at the right time with an appropriate level of quality?

Unless you’re building safety-critical systems, you don’t need to deliver perfect quality.   You only need to deliver just enough quality, focused on the right areas.

Is your perfectionism holding you back?

What is keeping you from deploying that code today?  What is keeping you from making that deadline next week?  It may just be endemic perfectionism in one or more parts of your team.  Go find that person right now and reset expectations with them before it’s too late.  You can still save that project if you act now!



Are you ready for the real-time web?

Our team has deep expertise in UX, design and development for the Real Time web.

Don't fall behind on the latest technologies! Sign up now for monthly updates from our blog and our RealTimeWeekly.com newsletter which has the best content from across the web on real-time development with frameworks like WebRTC and WebSockets.

Oh yeah, we have a book too!