2 years, 10 months ago 0
Posted in: Post
Zen and the Art of Feature Development

People who have worked on a variety of teams or for a variety of companies have—no doubt—noticed that high-functioning teams are are 2 – 10 times more productive than those who aren’t. And, in fact, when you’re working on a team that is in synch, it’s fun. It does feels like a well-tuned machine, where deliverables are happening on schedule; issues are identified in advance and are dealt with; and product features are happenin’.

So, why is it that some teams hit this groove, and others just don’t? More importantly, what can you do to turn a team that’s just getting by, into a high performing team? Why is this easier in a small team, or a startup?
In First, Break All the Rules (a great book on management), the Gallup organization found that a person’s answers to five questions were essentially predictors of their desire to stay at a company. They are:

  1. Do I know what is expected of me at work?
  2. Do I have the materials and equipment I need to do my work right?
  3. Do I have the opportunity to do what I do best every day?
  4. Does my supervisor or someone at work seem to care about me as a person?
  5. At work, do my opinions seem to count?

First, Break All the Rules is not a book that offers the standard rear-view mirror approach to management. It’s by a research organization that pries apart some fundamental truths about people, managers and organizations via surveys, statistical analysis and good insights—analytics, not platitudes. It suggests a number of good methodologies for hiring and working with individuals.

But, one thing that it doesn’t really deal with is how you create processes that help to positively affect these questions/issues. In other words, it provides a good backdrop for managers to think about issues like setting work goals and about how personally they engage with teammates. However, it doesn’t suggest ways to run a group in a fashion that promotes these elements (and maybe that’s just because it’s difficult to generalize process solutions across industries).

For example, what does it mean to have the opportunity to do what I do best every day? Or, how about—at work do my opinions seem to count?

There is no doubt that holding people responsible for achievable objectives, and guiding them through the steps needed to help reach those objectives is essential. Knowing what is expected of you is really the cornerstone of job satisfaction and productivity. If you don’t have clarity, nothing else will follow.

But the question still stands—how do you build a team that has a rhythm? What kind of organizational framework or tools encourage engagement, communication and dedication to a shared goal?

If you want a shared goal, you need a shared vision. And to achieve a shared vision, you have to get people to put skin in the game, which is most effectively done by making everyone participate in the process of helping to develop that vision.

This is consistent with the idea (shown below) that the path to any ideal solution is almost never a straight line. It involves iteration and feedback from team members (and hopefully, customers) can help a designer or product manager craft a superior solution. So, making team members a part of the solution results in greater buy-in and a higher-quality outcome.

Source: Design Criticism and the Creative Process by Cassie McDaniel

There are a number of things that my team does to help accomplish this:

  1. Be very planful in setting Sprint goals at our Sprint planning meetings. These goals are the most important deliverables for the Sprint. We explicitly review progress on each of the goals during standup. This keeps everyone focused; helps us make the right trade-offs when (important) distractions come up; and helps us fine-tune the handoffs between PM, Dev and Test.
  2. Ensure that Specs are delivered before the beginning of Development. This requires that they be started (usually) several Sprints before Dev is expected to work on them.
  3. Go thru a process of progressive refinement in feature conceptualization and development
    • Problems: Define the problems we are trying to solve and the subset of users we expect to address with those. These are the “pillars” of the release, and are really define the big buckets of functionality we want to provide (meet, get feedback)
    • Experiences: Identify the “experiences” that address the problems identified above. In this context, an “experience” is a the way the problem might be solved, with some suggestion as to how the user interacts with the program to accomplish it (meet, get feedback)
    • Features: Once the experiences have been defined, come up with a number of different mock-ups to help team members understand what a feature might mean from a UX point-of-view. I typically use Balsamiq, Viso or PowerPoint (UX toolkit) to create these. This helps puts some flesh on how the feature might look and work (meet, get feedback)
    • Detailed Investigation: For the feature implementation that’s been chosen, we usually do quite a few more mockups, and occasionally a Dev investigation into some of the complexities and technical issues surrounding the feature. Some of the technical realizations lead to additional functionality and/or improved UX in the final feature.
    • Specs: When we understand what it is and how it’s (generally) going to work, then we dive into the details.

This general framework is shown, below:

An example of the way that we scripted a particular “experience” (rich content widgets) is:

And, the way that is articulated in a mock-up is:

Despite the meetings and discussions, this kind of process is fast. There isn’t a lot of formal spec writing that goes on until the very end. And, a lot of thinking happens up-front.

Probably the most valuable reason for following this kind of a process is it engages the rest of the team in helping you figure out what you should build. This not only results in everyone having “skin in the game,” but it invariably means that the solution you come up with is going to be higher (usually much higher) quality, as it enjoys the collective perspectives of a team’s worth of people instead of one individual.

And, circling back to my initial point–engaging people in a robust process helps them have the opportunity to do what they do best everyday. It helps them understand that their opinions count. And, at the end of the day, it helps you build a more functional and productive team.

Some additional, interesting reading:
Lean UX at work

Lean UX for startups (start around slide 14)

Leave a Reply