SevenTablets First Happy Meter Results

As promised in my July post “Are Your People Happy?”,  I am sharing our own company wide happy survey experience with our trusted readers.  The happiness metric has always been maintained in product development but I received buy-in from leadership to administer to all members of our company community.   We followed all the guidelines in the July posting and ended up with an overall score of  4.4 out of a perfect 5.0  with an accuracy level of about 86% confidence.  In addition to the ratings, about 80% of the members that did participate in the survey results provided suggestions on what we should either ‘stop doing’ or ‘start doing’ in order to benefit the team and/or company overall.

User-Centered Design: Part 1 – New Software Development

The majority of our consumer market today expects software to be a service along with cloud access to data on any mobile device platform.  As software provider’s, we must extend our user-centered design approach to include mobile device views out the gate.  Most credible resources on interactive graphic design will use software providers LinkedIn, Google and Facebook as examples of great mobile user experiences.  I agree, but would these web leaders have made the same design decisions had they started out with a device-centric approach?

When Are Agile Requirements Ready For Development?

As a product owner on an agile development team, I am responsible for populating the product backlog with a list of user stories to communicate the product direction.  In layman’s terms, a traditional lengthy requirements document is broken down into small parts that are formatted into a simple story told by the end user in hopes that anyone should be able to comprehend.  For example, “As a product owner, I need to add an attachment to a user story so that mock-ups are available for team members to reference.”

Eliciting Honest Employee Feedback

In the office I spend part of my time researching the ROI on employee happiness.  One of the toughest parts to figure out before culture shocking your company is to establish the current situation as told by each employee, not the HR Director or the CEO.  The simple method of initial discovery is through a company wide survey or a couple of poll questions.

10 Heuristics of User-Centered Design

Lately the hot topic is UX (user experience) techniques and how to apply the best one to mobile.  This week I want to bring attention back to the ten timeless heuristics of user centered design as written by Jakob Nielsen.  In college we spent one full semester memorizing and applying them to our senior class project.  They are called “heuristics” because they are actually rules of thumb rather than specific usability guidelines as provided by iOS.  Please the following items as a checklist for any design you release.

Communicating the Product Vision

What are we supposed to build?

One of the most important responsibilities of a Product Owner is to communicate the product vision to all members of the organization. Not only is understanding the vision critical to product development and delivery, but it is also essential that everyone buys into the vision in order to contribute efficiently. For best results, spend time selecting appropriate modes of presentations per each audience type based on their needs and respective roles.

This week, I am sharing advice on techniques to present the vision and on how to maintain this information when you have adopted an agile methodology in which you are most competitive with a 'just in time' approach to planning.

Retain Talent Through Recognition

Most CEOs will tell you the most important asset is their employees.  Most human resource directors will tell you the most challenging problem facing them today is finding and retaining talent.  After diligent recruiting efforts and waiting longer than the market does, you build a great team of mixed individuals that have the potential to produce amazing things.  In addition to supporting an agile environment, companies must dedicate time and capital to implement recognition programs as part of the business model to retain their most valuable assets.  Not just key employees, but ALL employees should have the opportunity to earn public recognition from their peers, managers and executive team members. At the end of the day, we all like to feel appreciated.

Top 10 Mobile Release Considerations

Your initial release is going to be the one you have the least control over when it comes to planning which product features bring the most business value.  The reason you are constrained is because certain things must get done and decisions need to be made for the first mobile app release.   This weeks post is most useful to experienced teams that are new to mobile development and need a cheat sheet on what are the most important things to know when planning the initial release.  Since we are agile, the goal is to release an acceptable app early to market without sacrificing too much quality that you can not respond soon enough to market feedback.

Top 10 Considerations For Mobile App Release Planning

1. What device(s) and operating system(s) is your app compatible with?
You should keep track of the OS version and build number of the devices being used by the QA teams in conjunction with the code updates released by the development team.  Even if you are using a cross platform mobile development framework, it may not make the most sense to worry about all mobile devices this early on.  Shave time by choosing Android platform and indicate the compatible devices and software version. iOS will take a lot more time to get the first app submitted and approved by Apple, this does not include the timely process of activating an iOS developer account.

Is Your Team Happy?

Studies have proven that happiness is the key to success and longevity.  Many companies will use incentives or rewards as a means to increase productivity but there are challenges to keeping employee’s motivated for a consistent period of time.  Employers can only do so much to keep their people happy, people need to figure out how to make themselves happy.  How awesome would it be to start tracking the happiness of your employees to increase productivity in the workplace?

The key to measuring happiness is through continuous iterative cycles of inspection and honest feedback from employees.  I attended Jeff Sutherland’s latest webinar on the ‘Happiness Metric’ and I wanted to share some of the ways you can measure the happiness of your employees. The simplest way is to ask them using a short survey of questions and quantify the results.  Each culture is different so you may adjust the questions a couple of times before you can make correlations to the P&L.  Here is a sample set Jeff’s COO suggested I use on my last project.  I administered this exact survey to 5 different feature teams (6 members each), keep reading…

Number 1 and 2 are the only questions quantified for the metric:

1. On a scale of 1-5 (with 5 being extremely happy) How happy are you feeling about your role? (Indicate Role)
2. On a scale of 1-5 (with 5 being extremely happy) how happy are you feeling about the company overall?
3. What were the leading factors that increased your happiness since the last survey? (Give example)
4. What factors reduced your happiness since the last survey? (Give example)
5. Do you feel like you understand the product vision? (Team)
6. What is the one thing the team could do differently next sprint that would most increase your happiness? (Improvements)

Discipline is another key ingredient to creating hyper-productive teams.  Having your employees tell you how they feel and then doing nothing about it is counter-productive.  So here is the warning label for this article: WARNING: DO NOT TRY THIS AT WORK IF YOU ARE NOT SERIOUS ENOUGH TO IMPLEMENT CHANGE.

We will use metric again here at Seven Tablets and reformat it to suit the whole company, not just the product development teams.   The culture at our company is all about success through creativity and happiness.  Keep posted on my blogs and I will share the results in a couple months including  how to get everyone to adopt the survey.

Timeless Usability Principles that every professional UX/UI designer should know

These are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Match between system and the real world

The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Flexibility and efficiency of use

Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

MetaScrum - Maintaining Product Priority Order in the Company

The MetaScrum is the meeting where all decisions product are made and/or heard by representative decision makers from all areas of the company.  Typically this is a weekly meeting run by the Master Product Owner and supported by the CEO.  The agenda includes a charter of meeting rules, objective, current sprint status update and upcoming sprint plan. Depending on the company culture, more items may be included that impact the product release cycles.  One of the most important rules to enforce is that all priority order changes must be made in the meeting and supported until the next meeting. These meetings can be critical to helping the product management and development teams focus on getting things.

I will be posting links to sample formats and documentation.

Implementing new user experience design

When it comes to agile requirements, user experience and creative design implementation often becomes a challenge especially for large organizations.  I have many different approaches to recommend but I will share one way that was wild successful for me.

Assume the user experience flow will require refinement after the screens have been developed and after real end users have used the system in their physical environment.  The key is to partner closely with your customers at any given time in your planning, development and release lifecycles.  

Below is a phased approached. Make sure you have thoughtfully identified minimum task completion, don't try to solve the experience for everything in your roadmap. If you listen to your market, they will adopt new feature flows and experience changes if you always do the right thing.

Phase1 (Mockup, Design, style guide and slices)

-------------------------

- Basic look and feel design and core user conventions. Conduct story mapping and identify only what tasks are necessary.

- Usability testing and feedback sessions with clients, user groups and CMIO panel

- Upload designs to central repository for review by all SMEs and front end architect. Time box feedback and move on.

- Work with product analysts or BAs to finalize user stories

- Requirements ready for development

Phase 2 ( In Development)

-------------------------

- Implement Design using artifacts provided by Creative

- Creative available for questions

Phase 3 (Beta Feedback and Refinements)

-------------------------

- Review implementation by development, make recommendations and refinements

- Beta Test Case feedback from client and product owner

Helpful Tips - Scrum Feature Teams

Scrum feature teams make up vertical slices of areas of expertise to form cross-functional teams.  Feature teams can help a company scale by allowing team to take ownership of active projects in-flight that must be released in parallel.
Please note, unless your architecture is stable and modules are completely stand alone, be mindful of how many major features are being releasing in a given sprint. I recommend the team limit the number of active projects and never start a new project until the current one is 'shelf ready'


Helpful Tips for Choosing Feature Team Members
* There must be a Lead Product Owner or Master Product Owner that oversees all the inputs and outputs
Per each feature team:
1. One Product Owner.  Each feature team should consist of only one product owner. I will start another discussion on this topic when the same resources are responsible for projects belonging to different product owners.
2. One ScrumMaster.  An experience ScrumMaster is recommended to teach both the product owner and the team to work through sprint goals.
3. The Team. Try to keep the team size limited to three to four developers and no less than one IT QA staff per feature team.

Helpful Tips for Training your Feature Teams

For members new to Scrum
1. Make it very clear to all team members that no one is the boss, it is a horizontal org chart with everyone answering to the client.  Everyone is a subject matter expert of their team function. Each person is held accountable for their role and responsibility during the sprint.
2. If teachers are limited, train development first. Developers appreciate Scrum if you point out that requirements and priorities do not change after the sprint is locked and committed to by the feature team. Check out Jeff's article on shock therapy - http://scrum.jeffsutherland.com/2012/01/scrum-shock-therapy-how-to-change-teams.html
3. Train Product Owners on how to write a user story and break it down into manageable parts. Provide high level training on the Scrum Framework, don't reinvent the wheel, use material provided by your Scrum Certified Professional or what is available on the Scrum Alliance.
4. VERY IMPORTANT - When the team completes estimations and goals can be selected, make sure there is a face to face meeting in which the sprint goals are clearly defined and committed to.  The ScrumMaster only locks the sprint goals when the expression on every team members face shows comprehension.
5. Define a Sprint Activity Calendar and Checklist per each role. This is most helpful when there are old waterfall mindsets on the team.
6. Let the feature team members attempt to follow the checklist according to their role, make the ScrumMaster responsible for ensuring all members complete a full set of checklists by the end of the sprint.
7. The Scrum Coach or Scrum of Scrum Masters must conduct one on ones with each team member on a daily or weekly basis.
8. RETROSPECTIVE IS KEY.  Inspect and adapt.  Train on what is most important, not on everything under the sun, or shall I say 'under the Scrum'.

KISS - Keep It Simple Silly

Every meeting room used for sprint planning by product management and development should have a laminated poster that says 'Keep It Simple Silly'. This advise is timeless when it becomes obvious that the teams are over complicating the software design.