Lean + UX + Agile.

Lean Startup, User Experience Design and Agile Development are all approaches to improve your odds of creating successful products. Are they mutually exclusive, or can you assemble them together to make a lean, mean product machine?

In November Pathfinder’s Bernhard Kappe, Amy Willis and Reid MacTavish gave a sold out talk at the Chicago Product Management Association to share their lessons learned in making products with Lean + UX + Agile methodology. We have produced a video of the event including the slides with a narrative voice over for your enjoyment. If you’d like to view the presentation on slideshare, you can do so here.

We’re extending this into a half day workshop on January 20th that goes into practical details on how to make lean startup work.

We will cover:

• Pragmatic Marketing and Lean Startup- which is right for you?
• Lean UX – Design as the differential gear between customer development and agile development
• How to run a successful inception
• It’s never too early for metrics and analytics
• Agile practices and pitfalls
• Continuous deployment and A/B testing
• Team composition and how to hire

If you’d like to join us, you can rsvp here: http://pathfinderleanux.eventbrite.com/

Share/Bookmark

This may be generic advice, but it might not be a familiar concept for those in IT working within a large organization doing validated software:

Once you adopt the practices described in my previous blogs about regulated software, you will find that you aren’t working alone anymore. The tight feedback cycles allow you to regularly check-in with the business and involve them in building the software. Once this happens, priorities and features will change. Early on they will change often. Don’t discourage this as its a good sign things are moving in the right direction. The people talking to your customers are directly involved in building features your customers will use. This is exactly what you want because it increases the likelihood that you will produce a better product. Now that you have left your IT bubble you must partner with your stakeholders rather than simply delivering to them on a regular basis. How do you effectively partner with business and marketing? Here are the difficulties you will likely face:

• Goals are different
• The phases and corporate dialect are different
• The time frames and processes for decision making are different
• Required documentation will be different and address different goals
• Stakeholders will feel comfortable giving verbal requirements, but you must document them, get them formally approved and finally build them into working software

How do you partner with the business and still meet your commitments? Follow the practices we presented earlier and stick to the following principles:

• Consistent focus on activities that add business value
• Build trusted partnerships
• Constant customer engagement
• Continual process and practice improvement
• Be collaborative and transparent
• Work together: No heroes, lone wolves, or cowboys
• Pay attention to the team and adapt as needed

Share/Bookmark

In a recent article, John Gruber masterfully compared Google’s and Apple’s software strategy. He insightfully concluded that Apple solved the software distribution problem through their app store therefore doesn’t have to rely on browser based software. As a result of that, they can have all the benefits of native apps. Read the article, I was impressed by its sobriety.

He does have a grave misconception that spans technologies in his following thoughts:

I’m biased, insofar as I consider Apple’s strategy more appealing than Google’s. But that’s because my interest lies in having the best possible user experience — the best-looking UIs, the lowest-latency responses, the smoothest animation, the most elegant designs. I share that interest with Apple.

The error is that Apple strategy does not lie in betting on native apps for “the best possible user experience”.

There are many Widows native apps that are horrendous. Flash, Java and HTML5 are all able to deliver equally good user experience. Most importantly, it is tremendously simple to create awful software in Objective-C, especially Cocoa. No, it’s not about the native apps vs. browser apps vs. any other apps.

Apple strategy lies in their approval process for the app store. That’s why you never get to see all the under-performing, ill-designed nonsense. Because it never get’s to your device.

I can conclude this because I’ve been developing for Flash platform for 10 years where that problems manifests in its fullest. People would often mention to me how they hate Flash because of the annoying advertising banners and non-usable web sites. I on the other hand have experienced some of the best software in the world in Flash.

How can those two impressions co-exist? Because Adobe doesn’t have an approval process for Flash software. Anyone can create and distribute whatever they can manage to compile. In such an environment, all kinds of good and bad work is going to show up. Bad work also gets associated with Flash and Flash ends up having a bad name.

Apple is smarter than that. They decide who is good enough to be associated with their brand. It’s their show and they are running it well.

Their interest lies in their brand image and profits, like of any other business. “Best possible experience” therefore, has nothing to do with Apple’s software and everything to do with how they run their business.

Share/Bookmark

Recently I have been tasked with researching options for video conferencing platforms that one can integrate with a software product. I will share it how I see it and I would love to hear what you have to say.

High expectations

We used to sit down at our desk, plug in or adjust the external web camera, turn Skype on and start chatting on our hard-line cable or DSL connection. Dropped frames and pixelation came with it and we did not complain much because video chatting was sci-fi and quirks were expected.

Then we got used to the idea that web cameras come with our laptops, neatly positioned in the frame above the screen. We would again turn on Skype and hope that our home wi-fi connection wouldn’t choke with the overflowing data.

Today we like to complain how Apple’s Facetime does not work on 3G network. But we say, “Well, I guess I will have to connect my iPhone to one of the multitude of wi-fi connections around me and expend two clicks of my effort before I can start the video chat”. From pretty much anywhere. Having one camera on a mobile device didn’t seem to do the trick for us so one more was added.

When video chatting with just one person at a time wasn’t enough, Vidyo, Skype and ooVoo started offering multi-person conversations. And then they took it to mobile.

This is the environment in which we are developing right now.

Having video chatting so widespread by leaders like Skype, businesses started not only using such services daily but also incorporating them into their processes and services. A need has arisen to seamlessly integrate video chatting into existing and new software.

Who is out there?

Flash Media Server was the most popular and accesible solution for a long time. Adobe released a specification for RMTP protocol that other people used to create their media servers like Wowza and Red5. Vidyo came to the scene is 2005 and created waves with their patented Adaptive Video Layering Architecture. GTalk joined the scene recently supporting XMPP protocol and Skype SDK is currently in a closed beta.
While there are many other good video conferencing services, the ones above are what developers have to work with.

How does mobile come into play?

Since mobile is such a big part of video chatting today, imho it is critical that anyone offering SDKs has a solution for it. While there is a RTMP implementation for iOS, I haven’t worked with it so I can’t speak to its quality. That used to be a big hurdle for Flash Media Server and its siblings. For that reason, Wowza added support for RTSP/RTP and MPEG-TS protocols so you can stream content to iOS and other platforms. Vidyo has an API for iOS and Android. That makes Vidyo, Wowza and potentially FMS the best candidates to focus on. When Skype goes public with their SDK they might join the list.

Who has the best quality?

Vidyo, simply put. Quality is what they are all about. They architected their solution from the start for Internet conditions, meaning they built the system with the expectation of questionable network connection quality. Vidyo also helps power GTalk’s video conferencing which speaks highly about their capabilities.

That does not mean that Flash based solutions are a throwaway, far from it. But a side by side comparison puts Vidyo solution ahead by a critical difference. Let me explain. Let’s say that in a RMTP (Flash) conversation that lasts two minutes you have the video freeze-up for one second. That amount of loss is acceptable and expected. Chances are you will not loose a critical piece of information in a regular conversation. But let’s say that you are not in a regular conversation. Let’s say you are talking to your doctor or communicating via sign language or just moving a lot in front of the camera. Let’s say your business depends on the quality of video chat. That’s where Vidyo comes through. In my testing I haven’t had any video freeze-ups at all – ever. That makes the rhythm of the conversation much more human. It makes the experience feel like an in-person conversation because there is no reminders such as lag or a freeze that there is a technology between you.

Pricing

Wowza licence will run you ~$1,000. They also offer a developers edition free. FMS will run you between ~$1,000 and $4,500 depending on the edition. Both of them you have to host yourself or my personal preference, have an account with a service that hosts it for you. Influxis has been my choice for years. Not having to worry about scaling and maintaining hardware goes a very long way. Vidyo’s pricing is cut up into smaller pieces based on your needs and you can inquire with them about your case. They are pricier than the previous two.

Documentation

Sole reason for not considering GTalk and XMPP further is the state of documentation for it. While I have found some materials, it seems that there is no big effort to make it easier for developers to jump into it. Please prove me wrong. FMS has a huge body of documentation and a big development community behind it. Wowza is well documented and has a formidable community behind it, enough to have good chances of someone else having the same problem as you are. Vidyo’s documentation is impecable but I can’t speak to the community size. That doesn’t matter much because with Vidyo you have to get support which is fantastic if you can afford it.

Summary

Today, I would consider these three players: Vidyo, Wowza and FMS, in that order. Now I would love to hear about your experience with developing video conferencing apps!

Share/Bookmark

We presented our approach to implementing agile in an FDA regulated environment to a joint meeting of the Chicago Agile Project Management Group and Health 2.0 Group last week. This is based on our experience developing software for medical devices, and focuses on how to get the benefits of agile development while conforming to FDA regulations.

Share/Bookmark

You started a new job recently. Your organization has a some “legacy” apps, plus they’re working on a new batch using some cutting-edge technology. You’re assigned to a cool team with some hot-shot developers and ready do get down to work.

Suddenly, on day two, your manager walks by to let you know that the lead (and only developer) on one of the apps has resigned and will be leaving next week. Your manager asks you to pick up work on the project.

“Well gosh”, you think. “What a great opportunity to show my stuff”.

After a brief discussion with your soon-to-be-ex colleague, you realize this might not be a picnic afterall. The system seems to be functioning well and has a hefty backlog of pending work. However, when you inquire as to any form of documentation, you get a blank stare in return. Not only that, but the unit tests have been breaking of late, so most of them have been commented out. The build is manual and the deployment scripts work most of the time.

Well….now what?

Two suggestions come to mind:

1) Get in a room with your colleague and start a simple set of diagrams which depict the system top-down. These should be high level to begin with; a few architecture diagrams covering the technical and the conceptual aspects. Next ask about the complicated parts of the system and get some interaction diagram out on the white board. Next, make sure all the build and deployment information is documented and that they actually work (you can reproduce those steps yourself). Finally, ask about technical debt. Create chores to fix all the “we don’t have time to fix that now” gotchas. Lastly, take pictures of everything and write up the info in simple form. Posting on a wiki is helpful and if you’re using a tracking tool like Pivotal or ScrumWorks, enter everything in there.

2) Talk to your manager about introducing pair programming into the team to avoid this kind of situation in the future. Make sure you keep the unit tests passing 100% of the time going forward.

The moral of the story: while system documentation is important, it can be created just-in-time. A good practice is to use a wiki to keep all environment information logged and up to date. Trying to keep system document current is unnecessary as no one will read it until……at least he/she didn’t get hit by a bus.

Share/Bookmark

How many time have we heard some form of the phrase “it just a one line change”? Or “it shouldn’t effect anything else”?

I think we know the all to frequent result…..”I can’t believe THAT broke……!!”.

Good developers write automated tests to help surface side-effects like this before they get into production and cause real damage.

Good developer refactor code mercilessly to make modifications less error prone.

Good developers take the perspective that maintenance begin as soon as you write “just one” line of code.

Getting a version 1 product out the door is hard work. Keeping the cost of ownership reasonable afterwards, so others can maintain your code, requires a perspective of continuous maintenance.

Share/Bookmark

Quick! Think back to your most fond projects. Were they the most challenging or the most profitable? Maybe, but I bet you had a great team. I’m convinced that the most rewarding and successful projects share a common attribute, an outstanding team.

What makes a good team?

Is it a collection of rock stars that work 90 hours a week? Nope. Instead it’s people that work well together with copious amounts of respect and willingness to help other team members even if they don’t have the same role (developer helping BA, BA helping tester, etc). Good team members are:

• honest. It’s hard working with people that can’t be trusted
• good listeners. They don’t need to put forth their opinion on every topic.
• on time. You don’t have to be on time, you can be early.
• mentors. They enjoy developing junior team members
• willing to fill in gaps. Isn’t it great when a developer speeds up the build or cleans up the CSS?
• not complainers. Complaining is really contagious and has a big effect on morale.
• skilled, but always improving their craft
• respectful

Pathfinder is always looking for talented developers who thrive in team environments. If this sounds like you, please check out our available positions.

Share/Bookmark

We are big believers in hiring fresh graduates into our apprenticeship program. Get good people young and mentor them into outstanding agile developers.

We recruit graduates nationwide, but we do see a large proportion from the Midwest — Depaul, UIC, IIT, Loyola, Perdue, Indiana, Champagne-Urbana. As a result, we have good familiarity with the curriculum of those schools. For the most part they focus on Java in the classroom. At the same time they neglect OOAD (Object Oriented Analysis and Design) and OOP (Object Oriented Programming). It may see odd to teach an OO language and not give students the tools to do so effectively. It more than seems; it is odd.

Usually the folks we hire have shown a lot of personal initiative and done a fair amount of outside work on OO and things like unit testing. But a formal foundation in the classroom would make finding qualified candidates so much easier.

Now comes the news that CMU (Carnegie Mellon University) is dropping mandatory OO classes from it’s undergrad CS curriculum.

Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum. A proposed new course on object-oriented design methodology will be offered at the sophomore level for those students who wish to study this topic.

CMU is one of the premier Computer Science programs in the country. I find it disappointing that they are moving away from OO toward functional. I can’t argue with them about the advantages of functional programming. I like functional programming for two reasons.

1. Functional programming requires a lot of cleverness. Everything is a little logic puzzle. For a mathematician, it’s a ton of fun.
2. Functional programming is hard. Not everyone can do it and it reinforces my notion that I am cleverer than most folks.

As an entrepreneur delivering software every day, however, I’m not enamored of functional programming for those same reasons. You need truly exceptional developers to be able to cary off a project in a functional language. Also, simple things can be surprisingly difficult in a functional language (think of the amazing productivity of XSLT ).

Even OO can be difficult. The hill from Procedural to OO is not as steep as that to Functional, but not everyone can do it and they do need some training.

I think that what will likely happen with CMU students is that they will take the OO course anyway, or they will learn OO outside of school on open source or personal projects.

Share/Bookmark

Methodology

“The analysis of the principles of methods, rules, and postulates employed by a discipline”

For software companies these day it seems that its not a hard choice to follow Agile principles. With some practice, or hiring a consultant, you can learn Agile practices and employ them as well. Its an entirely different animal to decide you are going to use Agile practices in a regulated environment though. If you choose this route you must understand that you are on the leading edge of the rest of the industry. Here are some questions you should know the answer to before you can get started:

Photo By: susanrudat

What is Right for My Organization?

Most companies operating in a regulated environment are comfortable utilizing traditional software practices. This is often a waterfall approach. However, it may not be. Most Agile practices are not new – they are what good software organizations have been doing for years. Before you decree “We will be Agile” take a look at what the software organization is doing now. Do an inventory of the practices they are doing compared to something like Kanban or Extreme Programming. Before changing the process for process sake, ask yourself: Are they meeting deadlines set? Are you happy with the products they are creating? Does the overall organization seem happy with the software group?

If the software group isn’t delivering then using Agile practices can be a proven tool one can use to solve the problem. That being said, some organizations are extremely resistant to change. Being transparent, working collaboratively, and focuses on delivering software regularly can hard for somebody who has spent their career doing the exact opposite. In this case Agile may not something everyone can embrace easily.

How fast can the organization move?

Eventually a team that embraces Agile principles and practices is going to start moving faster than before. Make sure the rest of the organization understands clearly what is going to be expected of them. This will require open communication and and transparency by your team. There is no need to have a rockstar team that can’t move forward because the backend team isn’t able to deliver dependent software within your schedule.

Do I know enough about Agile?

My experience is that the most popular Agile templates out there (Scrum, Extreme Programing, Kanban, Lean) don’t directly lend themselves to building software in a regulated environment. This means are you going to be bending and breaking the “Agile” rules a bit. Before you can make your own path you must fully understand the “normal” path. Make sure you have significant Agile experience or hire that experience in before you start something difficult and try to expand on it.

Next Up: Have Some Class

Share/Bookmark