• Your Application Is Already Mobile

    by Raman Ohri

    We’ve been planning some mobile app dev with one of our clients for several months. This is basically extending two web-based systems we’ve developed for them to mobile devices. We discussed what functionality is useful to people in the mobile setting, security, what device and network to use, etc. Exciting stuff, and a scenario many people are involved in right now.

    Along the way, we had a critical and (in hindsight, obvious) revelation: these apps are already out there. The applications you have in production are already available to mobile device users. Tablet web browsers are nearly on par with desktop browsers. VPN from a device is easy. 3G and WiFi coverage are excellent. You can put digital certificates on a device, so two factor authentication is no barrier. Even desktop apps can be accessed by a plethora of remote desktop technologies.

    This turns the whole topic on its ear. Your app is already out there. Does it look the way you want? Is it accessible in physical locations that are security hazards? Is it frustrating users in new and terrible ways when they access it on their iPad or Galaxy Tab?

    The news isn’t all bad – this is opportunity. In some cases, we may not need mobile apps at all, just some refinement of existing systems. Most importantly, we don’t have to build mobile apps to start learning what we can do with mobile. It’s time to re-evaluate your portfolio of unintentionally mobile applications!

  • Oh yeah … I had a blog

    by Raman Ohri

    For all (both) of you who actually read this thing, sorry. I found myself posting nothing but book reviews, and there much better sources for that kind of information than me. I’ve got a few articles queued up and will attempt to get back on the horse.

  • Cool Resource for Software Engineers

    by Raman Ohri

    Last year we got rid of our traditional annual review system and replaced it with sensible component parts (career guidance, skill assessments, etc.) It would take several posts to explain the reasoning and mechanics, so just trust me when I say it was a Good Thing ™.

    One of the replacement systems is “one-on-ones”, a peer feedback mechanism. Periodically, everyone in the company is expected to reach out to a peer who has good visibility to their work and (hopefully) more experience to get some candid feedback. No form, no manager (unless that’s who you ask), no reporting other than the fact that it happened.

    We published some good topics for one-on-one discussion on our internal HR sharepoint site, but they are largely focused on the softer stuff, not much on actual engineering. Then we ran across this Programmer Competency Matrix. If you’re a software engineer, take a look … it’s a fantastic resource for self-evaluation and guidance. We haven’t formally incorporated it into our systems, but we’re exploring it.

  • Thanks, User Experience Guys

    by Raman Ohri

    An open letter to all you user experience people…

    Dear <state your name in full>,

    I started developing applications professionally in 1993. First Mac apps in the glorious 4D programming environment, then Windows, then Web. I’m now kept a safe distance from any development environments and left to do “manager stuff”.

    When I developed for the web, I created … let’s just say ‘functional’ user interfaces. My brief forays away from default styling were ugly and painful.

    bad ui 2 In fact, I was *proud* of my utilitarian interfaces. “I develop complex applications. I can’t be bothered with this trivial UI crap. That’s for web guys, I’m a software engineer. I do the hard stuff.”

    Fast forward to the last five years, when I’ve been inundated with all this user experience stuff. There was a time when I was proud to not even know what that phrase meant. Now, I’m surrounded … it’s everywhere I look. Jeff Patton, Jeff Atwood, Joel Spoelsky, Eric Sink, coworkers, clients, and even my darling wife.

    I grudgingly accepted at first. Even when our clients say “I don’t have money to make this pretty, I just need it to work”, they still want it to be not ugly, not unintuitive.  I get that. Many of our engineers at SEP have real talent in this area and started developing some beautiful applications. I still can’t create anything nice looking, but I get it now.

    But there was a horrible, unexpected side effect to this awareness.

    I see bad user experiences. They’re terrible. And they’re everywhere.

    I see you, terrible, irrevocable button sitting next to that harmless button. I see you (well, I don’t see you actually) feature that I use all the time in application that I use all the time that’s nearly impossible to find. I see you, buttons on my PC that are so poorly labeled I couldn’t pretend to know what you do.

    I see you, router configuration software. Every single one of you. <shudder>

    I see you Outlook, asking me to log in five separate ways every time I try to access work email via Outlook Anywhere.

    I see you, smart board software with your 50 icons and no hover text. Thanks for not using any industry standard icons. Awesome of you to create all new ones.

    I see you, Sirius/XM web pages for managing my account, where I COULDN’T GIVE YOU MY MONEY to turn on your streaming service.

    I see you Properties settings, moved in the last version of Word, and moved AGAIN in Word 2010 now nearly invisible:

    bad ui 1

    I even see (hear) you, astonishingly bad doctors office voice navigation system that made me listen to three minutes of chatter about swine flu vaccinations before I could even hear what the options were. (hint: I wasn’t calling about swine flu)

    So thanks, UX people. Really, from the bottom of my heart. I was happily ignorant, blissfully unaware. You’ve shattered that. I hope you’re happy with yourself.

    Sincerely,

    Me

  • Another Milestone for SEP

    by Raman Ohri

    The Lean Software & Systems Conference started today. This is the most SEP has ever been involved in a conference in terms of sponsorship, speaking, and involvement. Kelly Wilson, our fabulous organizational and marketing ninja  did much of the legwork setting up the conference and Chris Shinkle is speaking today. We also have four people attending.

    Chris will be giving a fresh new talk about Lean and Kanban in a Contracting Environment, with a heavy focus on Visual Controls. I’ve seen the drafts and it’s great stuff even if you’re not in a contracting environment. Visual control has been a bastard stepchild in the Kanban hubbub, but it’s immensely useful in any context and deserves more attention. If you’re in Atlanta, don’t miss it.

  • 3Q Book Review: The Trusted Advisor

    by Raman Ohri

    The Trusted Advisor by David H. Maister, Robert Galford, and Charles Green

    What’s the point? A friend of my boss recommended this book as “the bible of the professional service firm.” I have to admit it’s the first time I thought of my company that way. After reading it, I heartily agree. The book talks about the levels of relationship you can have with your clients, why and how you might improve those, and talks a lot about the ultimate level – the trusted advisor. This is not about tricking anyone; it’s about being earning the right to be someone that others deeply trust.

    How was it? I hated the first half of the book. Of course I want to be a trusted advisor. Of course it’s important. I know what wonderful things will happen when I achieve this. Yeah, I get it. The second half of the book was brilliant … really dove into the how with excellent examples from the authors’ careers. I saw a lot of things I have done poorly in this regard and gave me some advice on how to get better.

    Who should read it? Anyone in a professional services firm – except for my competitors of course! Maybe anyone in a mentoring or teaching role too… Screw it: anyone who cares about improving the quality of relationships around them.

  • 3Q Book Review: The Logic of Failure

    by Raman Ohri

    The Logic of Failure by Dietrich Dorner

    What’s the point? The premise of the book is that humans are notoriously bad at thinking through complex systems. We can’t plan or predict well and we don’t manage them well once we’re entangled in them. He presents a number of studies (real life and experiments) to explore this, discussing specific failure modes.

    How was it? Brutal. The stories were fascinating and I do not disagree with his premise at all (it’s pretty fundamental to how I perceive government). But the delivery … ouch. Un-useful levels of detail that go on and on. I wish there was more specific guidance there, but ultimately it isn’t a business book, so maybe not fair to ask.

    Who should read it? Decision makers in business or government (or caretakers of any complex system) would get value from the first few chapters and the last chapter or two. The middle is probably good content if your a psychologist. As a guy trying to be better at his job, that content was useless to me.

  • 3Q Book Review: Linchpin

    by Raman Ohri

    I really hate opening a blog post and seeing that it’s five pages long, 7 point font, dense text. Even if the author is awesome, it’s asking me to make a relatively big commitment. I’ll try not to be part of the problem … from now on, I’m going to do any book reviews in three questions:

    • What’s the point?
    • How was it?
    • Who should read it?

    I’ll start the latest from Seth Godin, Linchpin.

    What’s the point? The nature of the workplace is changing. If what you do is effectively a commodity, sooner or later you will be replaced. The people who won’t be replaced (the linchpins) are the ones create, invest emotional labor, who really affect the people around them (positively). The book gives an argument for the validity of this theory (a few too many pages in fact) and talks about how to be a linchpin.

    How was it? Very good. As a recruiter and middle manager, I totally agree … the people I value most in the workplace are linchpins by his definition. One of my favorite bits of the book: the art vs. the job. The art is the good stuff. It’s hard, it’s scary, it’s risky. The job is easy, it’s safe, you know how to do it. The part of you that craves safety will fill your day with the job, preventing you from taking the risk of doing the art. So true …

    Who should read it? Pretty much anyone in the workforce. It really doesn’t matter if you’re a software developer or a barista, the lessons apply.

  • Story Mapping – Quick Follow-up

    by Raman Ohri

    In this post, I talked about ways our teams could get started using story mapping (and associated techniques) that we get trained up on by Jeff Patton.

    So anyway … forget I mentioned it.

    In less than two weeks since the training, we’ve had no less than four teams use these techniques with their clients. And despite the techniques being fairly new to our teams, the sessions were highly effective and drew rave reviews from our clients. Obviously, my input was not needed. :-)

    There’s a lot of training available in the software world, and we’ve experienced a lot of it. I can’t remember ever seeing new techniques a) get put in play this fast by this many teams and b) be this effective even without much practice. A great statement to the quality of our teams and the quality of the training.

  • Story Mapping – Getting Started

    by Raman Ohri

    In our recent training, Jeff Patton presented a structured discovery process centered around the story map and personas, neatly packaged into about a week of time. Some people in the training were worried that their clients wouldn’t be willing to commit this. Let’s tackle this from two angles: how to get a client to the table to do some serious discovery work and how to get some practice so you are ready to go when you get that opportunity.

    Approaching Your Client

    Engineers are pretty good at figuring out why things won’t work. Your client already has a nice requirements doc. They have already kicked off the project. They are extremely busy and couldn’t possibly make time for this. The schedule is tight enough already. They will be put off by the note cards and the drawings and the paper prototypes and walk out.

    If you approach your client with that mindset, then you will fulfill this destiny.

    What if you approached it with this mindset instead:

    If we don’t figure out the real goals of this project, we could waste hundreds of thousands of dollars. We could hurt rather than help someone. We could completely miss that market opportunity.

    Delivering this sort of message requires some skill, but if your brain and heart are in the right place you’re much more likely to succeed. Here’s a sample opener:

    “The requirements document you provided looks great. There’s a ton of valuable information there and we will definitely dive into it. I’d like to supplement this with some discovery sessions where we talk with you and your team about the project. In our experience, these sessions provide real depth to the requirements, really help us understand the ‘why’ instead of just the ‘what’, and save our clients time and money. We have a fairly painless process for this that I can tailor to your needs.”

    Translate to your own words and give it a shot. Be confident … you are taking care of your clients.

    Getting Practice

    We aren’t all in a position to go offer this to a client right now. What can we do to practice so that we’re ready to go when the opportunity presents itself? Here are a few ideas:

      • Pick a portion of an existing project you’re working on and use one of the relevant techniques (story mapping, personas, paper prototyping, etc.) Afraid that it will take time away from development? What are the chances that you’ll learn something important about your project that completely dwarf that time investment?
      • Look at an internal or pet project, and apply the discovery process to it. You don’t necessarily have to move on to the actual development afterwards (though your stakeholders will probably be excited by the end of it!)
      • Story map or model the users a project you’ve already done.
      • Do paper prototyping for an imaginary product with volunteers in the cafeteria at work. Or your kids. Or your parents.
      • See if you actually know the outcomes for your project. Once you realize you don’t, go learn them.