The Unified Theory of Resource Management

While the law of competition may be sometimes hard for the individual, it is best for the race, because it ensures the survival of the fittest in every department. - Andrew Carnegie

In most companies there is a constant competition for development and QA resources.  The fight to get the most skilled of these resources can be downright vicious. We all believe the best people should work on the most important projects, but what is "most important" can be very subjective. Often it is politics that takes precedence when making decisions around resource allocations. 

To further complicate things, now that these resources are sequestered in scrum teams or scattered geographically, having a full understanding of who is really good and who is not can be challenging. We are often reduced to relying on the opinions of others.  

These two task occupy a great deal of deal of time and money in organizations.  They destroy productivity as well as employee morale.  What if it were possible to clearly know who the best resources are and easily assign them to the most business critical projects? Fear not, I have created a method for doing just this; I call it my Unified Theory of Resource Management (UTRM). 

UTRM is built around one central tool: a quarterly resource draft. At the beginning of every business quarter, all development and QA resources are put into a pool to be drafted by the Product Owner / Scrum Masters of the different scrum teams.  The order will be determined by the team's impact on the bottom line (profit or savings) the previous quarter. Those with the greater impact will pick first.  Obviously the teams that are performing financially should have their pick of the best resources.

 The teams can draft any available person from the pool or trade their pick to another team for whatever they deem valuable (server space, office location, cash, etc.).

The immediate impact will be the allocation of the best resources to the most valuable teams.  Product Owners will prioritize their work based on the greatest financial impact.  Scrum Masters will be focused on their team's productivity and making sure to document the most meaningful metrics as a means to show productivity gains (cost savings).  Business sponsors will understand  (or quickly learn) the impact of not having the best possible resources and will accept their role in helping the team succeed financially. In other words teams will now be more strongly motivated to ignore distractions that come up in every organization.

The secondary impact will be the ease in which managers can identify high and low performers.  In fact the entire organization will clearly know who is who in the organization.  This will pertain to all employees as the draft order will reflect the success of Product Owners, Scrum Masters, business stakeholders, etc.  There is nothing like a public evaluation of a person's performance to elicit change.  A couple straight quarters of being the last developer picked should send a clear signal to the developer and manager alike.  The NFL is a great example of a public performance appraisal.  There is no hiding on a Sunday afternoon and if you don't perform you are gone.

This is a radical change and many people would not be comfortable in such a transparent and competitive environment.  But those who are comfortable would be very competitive and relish a challenge.  Quite frankly these are most likely your high performers now.  They are the ones who work best when the pressure is at its highest.  They are the ones you call when no one else can get the job done.  UTRM will allow these people to receive the recognition and rewards they deserve.  On the other end of the spectrum, those awkward conversations with a low performer, who has delusions of their own work quality, will no longer be a surprise.  It is impossible to argue with the results of UTRM drafts. Most would see the writing on the wall and move on.

UTRM takes Jack Welch's performance ranking to the next level by providing a transparent and uniform measurement which everyone can understand. It will only take a company brave enough to implement it to see just how effective it will be.

Users are Idiots

     A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. - Douglas Adams 

1.       Users are Idiots: Keep your designs simple, because even the most obvious Use Case will be misunderstood. Imagine your users as a grandmother with ADD. Remember this, McDonalds put the pictures of their menu items on the register to simplify checkout for their employees; all of their employees still have to go through training.  

2.       Users are Idiots: Ignore their design suggestions.  If they had good ideas, they would be UX professionals.  Don't ignore their incessant whining because they do know what they don’t like.  Unfortunately, the gold nuggets of good design are hidden in those complaints. Listen to users when they explain what they do and then design the best possible interface to accomplish it.  Users are not designers and they should not design systems.

3.       Users are Idiots: Make no assumptions of any actual business knowledge.  Most of the drones simply do the same thing every day without a thought to why. When you change something (anything) they will complain.  They will ALWAYS prefer the old way, even if it involved physical pain. Expect this reaction, no matter the change. Just because users initially hate something, does not mean it is actually bad. Focus on making the task simple and the interface intuitive. If you accomplish these goals, your design will easily fit into their daily task and will soon become indispensable. 

4.       Users are Idiots: Never forget, we are all users. We all want systems that solve OUR problems without any real regard for the bigger picture.  This focus blinds us to the needs of other users.  Keep this in mind when you find yourself on the other side of the UX discussion. 

The purpose of this post is to define the role of a user in the system / UX design process.  I used a certain amount of hyperbole to make   my point, but with the growth of Agile development, a huge emphasis has been placed on receiving feedback from users as part of the development cycle.  It is important to keep a perspective on the type of feedback that is appropriate.  I have been part of product demos where users made design decisions.  This is a sure path to creating an piece of useless software to all but those making the suggestions.  

The user is critical to defining what it is they need to do; it is up to the designer to best define how to do it.  

Latest APP update

Finished the coding on Sunday, but I need to get it loaded on my watch to test.  I don't trust testing the sensor on an emulator.  The latest version of the Android Wear APP is VERY buggy and is inhibiting my ability to get the code on the watch to test.  Hopefully I can get some time this weekend and get it resolved.  I would like to test it out a couple weeks in the "wild" before uploading it to Google Play.