Citrrus Blog

How Do I Love Thee, Nike Training Club App

terumisu — Thu, 17 May 2012 09:47:43 -0400

Let me count the ways…

You’re confident and focused. You’re not worried about being everything to everybody. No. You know your narrow audience well and you cater directly to us. This app is for women! Current athletes, former athletes, wanna-be athletes — it doesn’t matter to you. As long as we are here to sweat, you’ll provide the guidance we need, at our level, for our specific goal. Thank you for not confusing our relationship with Twitter feeds, in-app messaging, friend requests, or a new fangled calendaring system. We’re here to do one thing. And that’s ok by you.
You speak to me. GET LEAN, you say? Yes. But let’s start slow, I’m a beginner. A modified burpee? I’m not even sure what a… Oh you have a video? And you’ll pause my timer for me while I watch and learn? That’s so thoughtful… 15 more seconds in plank? Ok. I can do that. For you.
Your beauty isn’t overworked. Oh, that UI. You minx. I love your clean lines and minimal color palette. That font. Nice choice. It’s bold without being aggressive. It’s tall and thin without being fragile. Just like my future self. I don’t mind that your tab bar is native, you spent your time enhancing more important features.
You know exactly how to encourage me. The bonus workouts. The healthy recipes. The badges of honor. I’ll be a Rebel in another 97 minutes. And I. Can’t. Wait. Yes, go ahead and schedule that Friday morning workout for me. I’ll see you at 8.
You keep your promises. You, my love, are an app of substance. I couldn’t walk for two days after our first meeting. I was sore in all the right places. You provide the workouts you advertise and you never get in my way. You let me access my favorites right from the home screen, view all my previous workouts, and preview the ones I’m just not sure about yet.

Thank you Nike Training Club App.

Let’s (Just) Do It.

Hugs + Kisses,
Terumi
A Very Happy UX Lead

________________________

User Interface: A
User Experience: A+

Form Follows Function: A Hard Lesson in App Design

citrruscreative — Thu, 10 May 2012 15:35:00 -0400

Here at Citrrus, our Creative team is hard at work taking inventory of the latest apps to hit the streets so our clients can benefit from cutting edge techniques to make their app a smashing succcess. Like a moth to a flame, we can’t help but dissect, sneer, and swoon over other designer’s work and find ourselves pinning up UI and UX elements to our Pinterest boards at an alarming rate. We chat a lot about good and bad examples that come across our desks and it would be selfish for us to keep that feedback to our whiteboards and wiki’s, so we’re officially kicking off #ThursdayThrowdown: where one app enters the ring and battles it out with the Citrrus creative team.

This month, we took on Columbia’s GPS Pal. If first impressions are anything to go by, this app made us swoon. With hand crafted details like unique typography, beveled table dividers, and custom tab navigation carried all the way down to the very last pixel—not to mention the dreamy splash screen—this app had us at “launch”. Take a look and you’ll see why:

But then we started to use the app. And that’s where our love-fest started to fizzle.

We discovered that it wasn’t very intuitive—the first few frantic taps left us hungry for a ‘get started’ guide and on tap #2 we reached an empty journal. The HELP section wasn’t very pleasing either. The texture was not as crisp as it is in the rest of the app, the fonts have weird bevels, and the FAQs are laid out in a boring table view that does not seem to have a logical order or keyword search capability. Since we are problem solvers, here’s a solution for the kind folks over at Columbia: try using stylized empty data screens or maybe tool tip hints to guide your users through their first few steps of creating content.

In the Journal screen (assuming you had a few entries stacked in there), the placement of the detail disclosure icon ignores Apple’s Human Interface Guidelines (HIG) of consistency and conditioned behavior in table usage. We rarely see tables where the detail disclosure button is not centered vertically in the cell and try to emplore this in most table apps we build for clients.

Another nit picky thing that goes along with Apple’s HIG recommendations of consistency is that this app chose to use a custom styled action sheet for socially sharing entries instead of Apple’s standard action sheet overlay. Most apps use the standard action sheet for sharing functionality—so much so in fact that we’re willing to bet most users could share on their preferred platform with their eyes closed. Recommendation: don’t ignore familiar behaviors; it will only trip up your users.

Like a bad joke that needs explaining, we were still waiting to get the punchline. As we started to track activities and load up a few journal entries we hit a major snag: how do you delete journal entries?! [insert broken record sound here] Took us a while to figure it out, but supposedly the only way to do this is through their Web interface. Tsk tsk, Columbia. Don’t you know that users expect to have the power to easily create and remove data? If you take away their power and make it harder for them to complete basic tasks, they probably won’t revisit your app much again.

All in all, we give this app a ‘Citrrus’ grade of:

User Interface: B+
User Experience: C-

Moral of the story: don’t put all your efforts into the lovely UI of an app at the expense of UX.

NSLog() - Avoiding performance problems

lennypham — Wed, 25 Apr 2012 14:10:21 -0400

Most developers make liberal use of the NSLog() function when developing and/or testing their code. You’d be crazy not to. Unfortunately we seldom remember to pick up after ourselves. And while you might think that it’s not a big deal, you’d be wrong. Leaving calls to NSLog() in your ‘Release’ code could significantly affect the performance of your iOS app.

Suppose that you’re developing an app with a UIScrollView or UITableView. And within the scrollview’s delegate you place an NSLog statement in the ‘scrollViewDidScroll’ method. This means that for every frame you have additional and unnecessary function calls which in turn consume CPU cycles.

Of course, no one likes cleaning up after themselves. So a quick and easy way to disable the NSLog calls in the ‘Release’ code is to define a wrapper macro for logging. What I do is define the following in my project’s .pch file

#ifdef DEBUG

#define DebugLog(…) NSLog(@“%s (%d) %@”, __PRETTY_FUNCTION__, __LINE__, [NSString stringWithFormat:__VA_ARGS__])

#else

#define DebugLog(…)

#endif

source: The iOS5 Developer’s Cookbook

Jeepers creepers, where'd you get those graphics?

citrruscreative — Thu, 05 Apr 2012 10:58:00 -0400

Jeepers creepers, where'd you get those graphics?:

Our Citrrus creative team is always on the hunt for design tools to make us more efficient and our client’s apps look their best. After all, first impressions and time-to-market are everything!

While swapping out our homepage banner and creating marketing collateral for BetterPress—our homegrown iPad publishing platform—we came across this pearl-of-a-resource: Pix Eden. It is a designer’s utopia chalk full of yummy PSDs that will instantly spice up your app’s marketing collateral with statuesque displays of iPads, iPhones, and other Apple-related products. All of Pix Eden’s downloads are free for use in personal and commercial projects and saved our creative team a ton of time and money—and heck, even make us look good!

So let this stand as our public proclamation of design-love for the folks over at Pix Eden. On behalf of our creative team, thanks for the graphic goodness you’re pumping into the world!

Caveat: if you read the fine print of Apple’s Marketing Guidelines (like we do) you’ll notice they have some specific preferences for how to display their product images—like only using front-facing images that do not overlap. We are big fans of rules and standards, but sometimes being professionals means knowing when to break the rules. This is one of those times. With premium-quality graphics like these, can you blame us?

BetterPress & Citrrus Featured in BRINK Magazine

citrrusmatt — Wed, 01 Feb 2012 12:40:59 -0500

BetterPress, Citrrus’ iPad publishing platform, was highlighted as a mover and shaker in the latest issue of BRINK magazine.

“this exciting group of entrepreneurs had brilliant insight and advice to share with our readers.” - BRINK magazine

The team at Citrrus would like to thank BRINK magazine for featuring our company in their latest issue.

Please read more about our company and our product in the latest issue!

LinkedIn Nailed It

citrrusmatt — Fri, 20 Jan 2012 09:18:00 -0500

I wouldn’t normally write about social media, mostly because it has been so sensationalized that there is little more to cover. However, I think the one thing that hasn’t received nearly enough publicity is the LinkedIn Today emails that receive periodically.

There is not a single publication or media source that has been able to capture my full attention like this email. While there are tons of excellent business and technology writers, remembering to browse through all of my favorite websites on a regular basis is too much effort for the off-chance of encountering a really intriguing article.

Now, I have found the “holy grail” of reddit/digg/stumble/del.icio.us (choose your preferred social sharing method) for people interested in technology, business and inspirational articles. LinkedIn Today provides excellent ‘must-read’ material, in a time when you could go on a journey through the articles produced each day and never be able to make it back home.

Congratulations, LinkedIn Today, you nailed it.

The Pitfall of Jobsian Management

citrrusmatt — Thu, 22 Dec 2011 17:58:00 -0500

In the wake of the release of Steve Jobs’ biography, I have heard a lot of people say that they now will aspire to create perfection in the things that they do. Steve Jobs was maniacally driven to perfect every product that his company released, and, as a result of that drive, the products that Apple delivered to the market have been pretty incredible.

Having said that, I am a bit concerned about what the future may hold for people in organizations where their boss has decided to take a Jobsian approach to management. Not because it’s a bad idea to have great products, or because throwing out a sub-par product after a long development cycle is a waste, but because only doing those few things will not make your company into an Apple.

Apple wasn’t great merely because Steve wouldn’t let crappy products roll out the door, but rather because of their culture and their values. People weren’t constrained by the parameters of how something should look or operate, they were inspired to think about things without preconceived notions. Steve wouldn’t let a product go to market if it didn’t meet his high bar for quality. He would challenge his employees on every decision, and shout them down in a bout of rage. Even though he did this, his employees and his company still thrived. For some reason this treatment didn’t phase them, or cause all of them to seek jobs at other companies.

The reason was simple: Steve had earned their trust, and they knew he believed what they believed. They knew no matter what happened, they were both on the same page about what it meant to be an employee at Apple. He wasn’t perfect, and for most people it would be a mistake to try and emulate his harsh leadership style. However, we can learn a lot from what he was able to accomplish in the short amount of time he was in charge of Apple.

People respond to values-driven management. They thrive in organizations that believe what they believe. They want to work in environments where they are challenged, and there is a high level of parity between their peers. They will rally around their leader when he or she has earned their trust and made their mission clear.

If you are hoping to create the same type of culture that was at Apple, start by changing your company’s values. Aspire to your highest virtues, seek to sell products that aren’t just ‘good enough’, but, instead, are better than anything else out there. Keep your profits honest. Provide high levels of transparency throughout your organization. Find people who agree with your mission, and push out the doubters. Seek to improve your core products, and don’t let quality slip in favor of growing your bottom line.

These are simple concepts, but they will change your company. They will inspire your people to do great things, and create an incredible feeling of hope that will be a beacon to your team, driving them to pull in the same direction.

Citrrus launches UVA Magazine for the iPad

ben-citrrus — Wed, 21 Dec 2011 09:53:29 -0500

Citrrus launches UVA Magazine for the iPad:

Citrrus is proud to announce the launch of The University of Virginia Magazine’s brand new iPad app! UVA is the first magazine to launch using our iPad publishing platform, BetterPress. We’re super excited to be helping content owners, like UVA, access the iPad through the simplest and most affordable solution on the market today. Check out our beloved BetterPress at http://www.betterpress.net.

Citrrus Founder Jason LaFollette Weighs in on the Privacy Debate

ben-citrrus — Tue, 20 Dec 2011 13:28:30 -0500

Jason tries to bring the boiling controversy over mobile data privacy back down to a low simmer in Security News Daily, saying:

“It is my feeling that privacy issues have not fundamentally changed. Wireless phones have always allowed carriers and government agencies to track users and computers connected to the Internet have always allowed users to publish private information if they aren’t careful,” he added. “Smartphones may have made it possible for people to get themselves in trouble anytime, anywhere, but their manufacturers have also explicitly recognized the problem and taken steps to put users in control.”

Check out the full discussion here.

Citrrus Partner Ben McGinnis Leads Hackathon Team to Victory in Challenge.gov Competition

ben-citrrus — Thu, 15 Dec 2011 12:22:00 -0500

A few weeks ago I went to the Digital Capital Week Hackathon and met some pretty cool folks. We coalesced around an idea for an app that would solve the problem of finding grants and competitions you might be interested in by using some smart filtering and push notifications. The idea became Small Business Alert, an app that uses the SBA’s API to pull information on upcoming SBIR proposals and Challenges, and alert users to updates.

I’m excited to announce that we’ve taken 3rd Prize in the challenge, which saw over 20 submissions. I’m very proud of the work we were able to do in such a short time. So a big shout out to Paul Murphy, David Curry, Simon Engelhardt, Herve Vu Roussel, Danny Kleinman, and Aaron Huttner for their awesome work on the project!

Follow Ben on Twitter

Moosejaw, Sears and others go mobile

citrrusmatt — Mon, 05 Dec 2011 09:45:00 -0500

Many large retailers have started to see the future of their customer’s in-store experience. It’s free from lines, allows their employees to interact with the customers on the store floors, instead of just at cash registers, and, as of right now, is a major differentiator.

Tight integration between point-of-sale devices, inventory, and supply-chain data will help empower employees on the floor to better assist customers by quickly checking for product availability, product pricing, product information and videos, as well as online purchasing of merchandise not available in stores.

The advent of high-quality, inexpensive devices with software that is programmable by anyone is a major leap forward in putting the power of the register into the hands of the sales associate. As more and more retailers begin to use these systems, the customer experience expectation is going to move toward a line-free environment, where the entire checkout process will be quick and painless.

Skin in the game

citrrusmatt — Fri, 02 Dec 2011 09:53:38 -0500

One of the most undervalued components of great company is the concept of top-to-bottom ‘skin in the game.’ The problem in many companies that should be able to produce great stuff, but fail to do so quarter after quarter, product release after product release, is that as their employees move up the ladder, their ‘skin in the game’ decreases. At each higher rung, many employees expect that they can forget everything they did in their previous role, and move on to the more important things for which they are now explicitly responsible.

The best managers and executives that I have worked for are passionate about their company’s product. They take interest in all of the details, and are constantly trying to come up with ways to improve their product or process. They think critically about each step in the development of their product, and have passionate internal debates on what the proper next step should be. They eschew and kick out the people who say ‘not my problem’, or ‘that’s not my department’. They step in and help when they are able. If they are a programmer, they might pull some extra hours programming new features. If they are a marketer, they might write up some new marketing material. If they are a UI expert, they might draw up new wireframes.

In contrast, what I often see happening to people, as they move up and enter into managerial positions, is that they forget they still play an important role in their company’s product. They lose their ability to pay attention to the details of the product, and merely focus on a delivery date or a number on a budget spreadsheet. They are better off economically, but at the same time significantly less valuable, productive and happy in their job.

Great companies expect more of their employees, and train them to notice the warning signs of when they are not in the right role or they have lost their passion. They expect them to do more than just push paper and hold a clipboard. They are there to motivate and inspire others to take the same pride and passion in their work as they used to. Great companies keep the idea of ‘skin in the game’ in the forefront of the minds of their people, and it comes through with every product they release.

The Democratic Party of Virginia has an app, why don't you?

ben-citrrus — Thu, 28 Jul 2011 11:25:28 -0400

The Democratic Party of Virginia has an app, why don't you?:

This post goes out to all of the elected officials, candidates, and parties out there who’re looking for an edge come election season. The Democratic Party of Virginia just released their new app, designed and built from the ground up by the Citrrus team. It seems that a lot of the political class out there has yet to realize just how awesome a mobile app can be for your campaign.

I see you there, rolling your eyes with skepticism, but think about it for a minute and you’ll realize the power. Tell me, how far away are you from your iPhone right now? A foot? Less? When you wakeup in the morning do you check your phone first? I do, and so does much of my generation (“millennials”). But you know what I don’t respond to? Snail mail (it’s nothing but dead trees to me). Email from politicians (thank you Other Inbox). Phone calls? Yeah right, if I don’t recognize the number I don’t pick up.

You know what I do like to get? Push notifications on my iPhone that tell me Barack Obama wants me to call congress. Badges for volunteering and donating so I can be Mayor of the District 42 Virginia State Senate campaign. Getting my story straight when delivering your message to my friends and family.

“Aha” you say? Good, I’m glad you finally get it. So call us and we’ll build you an app that’ll put your message in the pocket of all those wonderfully energetic millennials like myself.

Getting the Font Name for fontWithName UIFont Selector

citrrusmatt — Thu, 21 Jul 2011 12:28:00 -0400

It’s kind of a pain to programmatically set fonts on labels when developing for iOS, and most of the forums take you through a ridiculous mess of work to accomplish this simple task. Luckily, there is a way to make it easier.

First, you’ll want to get a list of font families available for the platform. You can do this by adding the following NSLog to your app delegate’s didFinishLaunchingWithOptions method:

NSLog(@”%@”, [UIFont familyNames]);

Note: Set your scheme to the iOS version and device you are developing for before running the app. Different iOS versions and devices have different fonts available.

Once you have found the font family that you want to use, you can get all of the font names for that family by adding the following NSLog to your app delegate again:

NSLog(@”%@”, [UIFont fontNamesForFamilyName:@”Helvetica Neue”]);

(replace ‘Helvetica Neue’ with the font family of your choice).

Coming soon… custom fonts in iOS

Friend with a Grooming Problem? Tell him about it with our latest App!

ben-citrrus — Tue, 15 Mar 2011 12:17:00 -0400

Does one of your male friends have body hair that’s out of control? Maybe they’re in denial about their comb-over, or their unique odor overpowers everyone in the room when he walks by.

Citrrus’ latest app for our friends at The Grooming Lounge, let’s you to discreetly tell him about his grooming faux pas, and shows him where to go to find help. Download it from the App Store now, and finally free yourself from living with the poorly groomed!

Citrrus' Take on Agile, Part III

ben-citrrus — Mon, 21 Feb 2011 09:00:06 -0500

Ok, so we’ve started out by discussing how our roles are a bit different, and how the initial phases of the progress are here and here. Today we’ll be talking about the rest of the process, starting with The Estimation Meeting.

The Estimation Meeting

While all of the parts of both Scrum and the Citrrus Execution Framework (also know as the “C.E.F.”- patent pending) are important to the success of a project, The Estimation Meeting is critical. The Estimation Meeting gives the team buy-in because they’re committing their stamp to the estimates and saying “I can get this done!” to the Project Owner, the Project Manager, and all of their peers on the team. This meeting also lets the Project Owner make important trade off decisions between features based on objective cost-to-benefit information, even if the benefits are often really soft (personally, I’ve never met a benefit that wasn’t soft). The Estimation Meeting also lets the team build all of the reporting that gives The Executive confidence that the team is being transparent and that they can make all of their Important Decisions and crow loudly to other executives (notice the small “e” on executives) about how awesome their team is. The Estimation Meeting also gives everyone involved in the project much needed evidence.

Evidence is one of those great artifacts of a process like the CEF. It lets you do crazy-detailed excel spreadsheet analysis about how good each estimator is at estimating different types of items. Maybe someone on your team sucks at estimating interface work (we won’t name names), because they’re such a perfectionist they’ll spend hours getting every little pixel aligned. But you know what? That same someone probably consistently sucks at estimating interface work. Most estimators are like the person-who-shall-remain-nameless and are consistently optimistic or pessimistic (the Montgomery Scotts of the world). This evidence is really helpful in projecting your actual completion date—and unless you’re an Excel wizard like I am—you’ll probably want to use a great tool like FogBugz. FogBugz is great for many reasons, not the least of which that it was created by Joel and the wonderful folks at FogCreek Software (who are kind of like our corporate inspirations). One of the reasons FogBugz is so great is that it builds on a concept called Evidence Based Scheduling, which takes into account every estimators passed accuracy and adjusts their estimates accordingly. This adjustment gives the team, the Project Owner, the Project Manager, and the Executive awesome transparency in their ability to predict the uncertainty of a software project. It tells them that when employee-who-shall-remain-nameless says something will take 4 hours, will really take 6 to 8 hours. That kind of power can really save a lot of heartburn.

Fortunately or unfortunately, I’ve got to do all my evidence based scheduling in Excel (can I have three cheers for Pivot Tables?) because FogBugz doesn’t currently support Beanstalk—our SVN—and so we use JIRA and Excel to get our projects done. What do you think Atlassian folks, could EBS be coming in JIRA 4.3?

The last thing the Estimation Meeting does is set the Product Owner up for the Release Planning Meeting (think a Steve Jobs Keynote… except with less actual stuff to show off).

I’ll be covering the Release Planning Meeting in my next post, same Bat Time, same Bat Channel.

Written by:

Ben McGinnis

Citrrus Project Mananger

There's a Human Using Your Technology!

lennypham — Tue, 25 Jan 2011 18:18:21 -0500

Take a look at your stove. Now ask yourself, “how many times have I accidentally turned on/off the wrong burner?” The stove is a fairly simple device with just a few knobs and a couple buttons. Yet, from time to time we get confused by the interface and perform the wrong action. It’s no wonder then that I often (read: all the time) get questions from family and friends like “I’m using the XYZ application on my computer and I need to know how to do ABC”. Now you understand why UI/UX design is so critical in developing an application (app).

The modern graphical user interface (GUI) has, for the most part, remained unchanged since the early 1980’s. Software applications consist of a Window, Icon, and Menu. Users interact with the apps using their keyboard and mouse. Desktop icons like files and folders represent everyday metaphors to visually assist the user. They are relatively simple concepts that evolved from a simple idea; In order to be commercially viable, computers (and software) need to be simple enough for a child to use.

So why is it so difficult for so many consumers to use modern software applications (apps)? For starters, apps are no longer bound to the desktop. Many traditional desktop apps have been replaced by online browser based apps making traditional desktop metaphors less common. Additionally, many desktop apps have started to mimic the web and vice-versa. From a UI/UX perspective this has led to a nightmarish hodgepodge of design concepts and metaphors that even for someone with a degree in Computer Science or Web Design can be quite confusing or overwhelming.

Now have you ever watched your mom, uncle, grandma, six year old niece, etc. use an iPhone or iPad? It’s a completely different experience for them, one that often requires little to no explanation because the learning curve is so low regardless of the app. So what’s behind this phenomenon? In large part, it’s due to Apple’s Human Interface Guidelines (HIG) for iOS and Mac OS. Though it is not strictly enforced, it is STRONGLY recommended that all apps submitted to the iOS or Mac app store follow the HIG.

The HIG provides software development standards for:

Performance
Ease of use
Appearance
Security
and Reliability

Gestures, navigation controls, layout, icons, etc. are described in great detail. The importance of the HIG is that it provides a framework and metaphors for interaction that the user is likely already familiar with. Most of the apps take a minimalist approach and because all iOS and Mac OS apps provide consistent visual and behavioral characteristics the apps are easier to learn and simpler to use.

A lot of voices in the software development community have criticized Apple for being rigid and close-minded for their app store requirements, but they’re simply not looking at the big picture. By following a set of well conceived design guidelines, we can develop apps that are attractive, full featured, and easy for consumers to learn and use. After all, it won’t be long before we’ll be using an iPad to turn the stove on and off.

Written by:
Lenny Pham
Citrrus Software Architect

Citrrus' Take on Agile, Part II

ben-citrrus — Mon, 24 Jan 2011 10:14:00 -0500

In our last post, we started to talk about our view on the importance of Roles and Responsibilities in an Agile process. Now, let’s go over the actual execution process and how we like to approach things with our clients. This will be just a brief overview as we’ll be discussing some of the most important aspects in separate posts.

Before we get going, we want to make a quick shout out to Green Hopper & JIRA, for not only making our process much easier to implement, but for giving us a bump in Web traffic by reTweeting our last post on Agile. So hooray for the @GreenHopperTeam! (Trust us, these tools matter. One of our clients is managing their SCRUM cycle with Excel and we’re fairly certain we’d make like Oedipus Rex and put out our eyes if we had to do the same.)

Now, on to the nitty gritty!

Initial Discovery

Since we’re primarily involved in making entirely new products or redesigning old ones from scratch, a lot of our process is front-weighted toward getting projects off the ground quickly. In order to really get things going we like to start out with an initial discover phase that lets us help the client really understand the purpose of their project and who it servers.

Part of what we offer is about helping our clients figure out their strategy for mobile devices. That usually takes place in a quick brainstorming session with the client or on our end where we try to explore their motivations and how mobile can improve or enhance their business. We’re not talking multiple meetings here people—the most important thing is getting in the room with your stakeholders, talking out the mobile marketplace with them, and making some initial decisions to explore in one strategic area.

After we have a good understanding of our clients’ goals, we like to do a Story Mapping Session with them. (sounds fun, huh?) It is! We can’t say enough how great this process is for really breaking down a new product into a digestible visual representation of the idea. This process was pioneered in 2008 by Jeff Patton over at AgileProductDesign.com. Fear not, knowledge-seekers…we’ll dedicate a whole post summarizing that soon. @GreenHopperTeam, if you guys are reading this, please make a “Story Map” view in some future update!

Backlog Management

This is one of our main differentiators from Agile/Scrum. The classic prescription from scrum is that every release you have a giant, million-hour meeting with all the stakeholders nestled around a stuffy conference table and whiteboard debating the goals for the next sprint. We think the process goes a lot more smoothly when the Project Owner is well prepared for this meeting. (you do have an appointed Project Owner, don’t you?)

The best way for the project owner to prepare is to be continually engaging with the stakeholders (the executive, the team, and everyone else) on how the project features are meeting their ever-changing needs. He/She also needs to be trying to put some normative value against the new feature requests. Here again, Jeff Patton shines in his distillation of concepts originally detailed by Noriaki Kano of the University of Tokyo (we just want to take a quick moment to give a shout out to our Japanese friends for producing so much excellent work on every facet of empirical management). Basically the concept involves features that constitute objective quality, like bugs, which are objectively low quality. There are also features that provide subjective quality, and they come in two flavors: one-dimensionals and delighters. The more one-dimensionals a product has, the more people love it, and delighters are things that produce true “Wow!” responses from users. One-dimensionals are often easy—like horsepower in a sports car—but delighters are the hard part, think the industrial design of the iPhone 4 (or any of Apple’s products—which almost universally elicit a sense of true elegance).

Back to the process….

In our view, constantly elliciting feedback from stakeholders and classifying features as must-haves, one-dimensionals, and delighters naturally produce a well-organized backlog and prepares the project owner for really excellent planning meetings that generate real passion amongst the team and the stakeholders.

In short, the best project owners are people who can channel Steve Jobs on a consistent basis and turn meetings into a usable planning artifact.

Okay, since the post is getting rather long at this point, let’s save the rest of the process for future posts….happy planning!

Written by:
Ben McGinnis
Citrrus Project Manager

Trust: The Key Ingredient to Getting Things Done

citrrustest — Thu, 20 Jan 2011 10:26:00 -0500

Lack of trust in your business partners may be costing you time, money, and a good night’s sleep. With all the NDAs, contracts, master services agreements, and other documents that have to be signed before business can move forward, it’s a wonder anything ever gets done and it’s probably not a big surprise that almost nothing moves quickly.

While, we at Citrrus, are not advocating doing business without any legal protection or documentation of deal terms, we ARE saying it’s time to shift the pendulum back toward simple contracts that can be drafted, read, and executed quickly. We’re also saying that it’s ok, in fact better, to start doing business with a handshake. Business is, after all, about building relationships, right? Having that first meeting or even starting work on a deal before every last contract is signed makes good business sense. Unless you like paying idle (or less than fully utilized) resources, then time really is money.

We know this goes against everything your legal department has ever told you, but they’re wrong. You wouldn’t let your engineers, your sales people, or any other support function in your company dictate the pace of your business, why would you let your legal department? One of our good friends—who happens to be a very smart and business-savvy lawyer—once told me that a Corporate Counsel’s job is to present the risk associated with different business decisions, not to tell executives what decision they should make. If your legal team writes such “great” contracts that no one wants to sign them, or multiple rounds of redlines always go back and forth, it may be time to consider whether they are supporting your business goals, or holding them back.

Lawyers aside, this all sounds undeniably more risky, right? Absolutely. But all business is about calculated risks. Unless you routinely do business with untrustworthy people (which we don’t recommend) it seems fair to say that you are going to have many more positive experiences than negative. You might also be surprised with how much stronger your business relationships grow, and how much better your deal terms become when you openly show willingness to trust your business partners. Think how much better you’ll sleep and how much more you’ll enjoy your job when you’re forming lasting relationships instead of constantly looking over your shoulder and expecting to be double-crossed.

When it is time to get some legal documents behind that handshake, consider expediting the process by using a service like rightsignature.com to review documents, collect signatures, and archive executed contracts. Not only will everyone know where they are in the process, but the ability to sign digitally is infinitely more efficient than faxing around hard copies and keeping large filing cabinets of loose papers.

Written by:
Jason LaFollette
Citrrus CEO and Founder

Citrrus' Take on Agile, Part I

ben-citrrus — Thu, 06 Jan 2011 19:37:00 -0500

Here at Citrrus, we have managed a lot of software projects over the years, and have tried every methodology under the sun to effectively organize our teams and get things done. We have used Waterfall, RAD, Adaptive, and Agile/Scrum just to name a few. You name it, we’ve tried it. Of all of the methodologies we’ve experienced, Agile has by far been the best fit for us. It has worked so well, that we’ve even started using it to manage all of our administrative and non-technical projects as well as software projects.

Most Agile advocates will tell you that while the out-of-the-box process is a great guideline, you really need to dig in and customize it to fit your needs. As a group of software developers that have always put business value ahead of technology, we have made a number of adjustments that we think makes the Agile a lot more friendly to business people, and clients, who might not be so down with Geek-speak and engineer stereotypes.

To give you a good overview of how we do Agile, let’s discuss how we define the roles and responsibilities for a project and explore more subtle process adjustments in a follow-up post.

First, let’s talk terms. Based on our experience, we’ve found that the terms Chicken, Pig, and ScrumMaster don’t really give Agile a lot of credibility with many business stakeholders. This is a huge problem since these are people who absolutely must be bought into the process. So, instead of using the popular ham & eggs metaphor, we like to simply be explicit: In every project there are people who are accountable for its success and those who are not.

So, who’s accountable for the success of the project and who isn’t?

Let’s start from the top with the role we call the EXECUTIVE (queue dramatic villainous music). the EXECUTIVE may be a single individual, or even a multi-tiered group of higher-level managers. This role is supposed to be the source of Strategic Vision for where the project will take the business. So, in short our vision of the Exec is someone who throws down a Big Hairy Audacious Goal (BHAG) and is on the hook to make sure the team meets the goal. That means that the Exec must know what’s going on with the project, but hopefully doesn’t have to actually do anything.

The PROJECT OWNER and the PROJECT MANAGER lead the project team and make sure everything runs smoothly day-to-day. These roles are a major place where our terminology and execution differ from Scrum. We’ve tried to make it a bit more generic, so that the process isn’t so software or product development focused, hence the substitution of “Project Owner” instead of “Product Owner”. The PROJECT MANAGER is our business-friendly version of the Scrum Master, which we think is a bit too hippie chic for the wider business community.

The PROJECT OWNER and PRODUCT MANAGER are the attached at the hip Siamese twins of the project. They must be so closely aligned with each other’s goals that the relationship can weather any level of adversity and conflict without destroying the trust between them. They need to be highly aligned because they are both mutually accountable for the success or failure of the project and neither of them can be successful without the other. Every sprint is a three legged race with these two out in front.

The PROJECT OWNER is responsible for making sure the Project is going to meet the BHAG set by the executive. It’s her job to define and prioritize the backlog and make all of the tactical business decisions that come up over the course of the project.

The PROJECT MANAGER is, as Scrum suggests, the remover of impediments, the arbiter of technical quality, the runner of meetings, etc. But we believe that she is also the explicit Team Leader, responsible for resolving personnel conflicts and doling out tasks if no one on the PROJECT TEAM is champing at the bit to do the job.

The PROJECT TEAM still self organizes to the extent possible, but in reality most teams need someone to resolve conflicts and coordinate tasks, and since most of us live in reality we think the PROJECT MANAGER is the right person to run things.

An example of the Self-Organization approach taken too far can be found, in this blog post on Mountain Goat Software’s blog. Here’s a quote:

Suppose you are a ScrumMaster for a team. You’ve noticed that one team member, Jeff, is domineering and no one is willing to stand up to him. This team has self-organized—it has chosen to let Jeff make all key decisions. As the ScrumMaster for this team, though, you recognize that if Jeff continues to make all the decisions on his own it will impede the team’s efforts to improve. You consider having a private conversation with Jeff, but that is unlikely to change much. You contemplate stepping in and overruling some decisions he makes, but if you do it once the team will expect you to continue to do so, which won’t be good.

Then you begin thinking about subtle control and influence. Perhaps you decide to change the team’s dynamics by asking management to add someone new to the team, someone who is likely to stand up to Jeff. Or maybe you suggest to the enterprise architecture team that someone from its group attend key meetings—someone with the experience and background to challenge Jeff.

If one of our Project Managers were in this sort of situation, we would expect them to actively step in and push the other members of the team to participate. The focus on subtle control of a team seems, to us, to be ineffective in almost every situation as it requires manipulative scheming, a large of amount of precious time, and of course, it rarely works. We believe that leaders should be straightforward and clear about what they want from their team. We believe they should lead.

Written by:
Ben Mcginnis
Citrrus Project Mananger