Tag Archives: team

Only You Care How It’s Built

Remember the last time you were really frustrated when using something? It didn’t work as you expected or you couldn’t find what you were looking for. As your attention focused on the people who built the tortuous tool, do you remember thinking to yourself, “That’s OK. I hear they have a great process.” No? The unfortunate truth is that the people you are building for will not care how you got there, only whether you solved one of their problems in a positive way.

I think this is one of the reasons behind the first agile value, “Individuals and interactions over processes and tools”. It is tempting, when integrating new practices, such as with scrum, to get caught up in the mechanics of a new process. There are new ways of working and new tools to learn, and these can take a lot of time, energy, and focus. It can be tempting to do things ‘by the book’ when first starting out, but that puts our focus on the wrong goal. The team is not there to perfect a process, but to deliver value to real people.

So why “Individuals and interactions,” and not “results”? Results don’t make a product, people do. The people are the invisible force that create the product. As one of the agile principles states, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Pixar’s Randy Nelson has a fantastic definition of collaboration not as cooperation, but amplification. A good team that works well together will amplify each others’ skills and abilities to create better results than they would as individuals. This definitely resonates with my personal experience. My best ideas usually come when I’m engaged with others, not when I’m by myself. Sure, I have a few Eureka! moments wearing headphones, pushing pixels, but the bulk of them come from the interaction with other minds approaching the problem from different directions, each with their unique personal history.

There are many elements that create an environment that a allows a team to succeed. As implied above, clear goals and measurable results is one. I’ll go into that and a few more in a future post. In the meantime, what is it about your environment that supports or hinders your team? Do you have motivated people? Do your stakeholders trust you to make decisions on their behalf? Are you focused on value? What have you changed about your environment that has had a positive impact?

As always, I look forward to your comments. Also, please take a moment to rate this post by clicking the stars below the title. It helps me know if I’m on the right track and I really appreciate the feedback. If there is a specific topic you’d like me to address, add it to the Suggest a Topic page.

Going Back to the Source: The Agile Manifesto

There are a lot of different ways to implement agile. That is one of its strengths. Agile allows you to create exactly the process that works for your team, company, problem, and client. However, it also gives teams the responsibility to create that process, and that is difficult. Teams typically can’t rely on doing things the way they’ve always been done.

Whatever practices are put in place, be sure that you are true to the agile values and principles. I’ve been interviewing with many companies over the last 6 weeks <shamelessPlug> (I am available for work in the Boston area) </shamelessPlug> and I’ve been surprised at how many people are talking about agile, have not read the manifesto, and think that agile is about sprints, daily meetings, and a lack of big upfront design.

Agile is 4 values and 12 principles. Period. It doesn’t say whether to do upfront work or not, or to work in sprints, or to have backlogs, or to start coding right away. These are techniques that some teams have used based on agile, and others have codified into practices such as scrum, but these practices are like the reflection of the moon in a pond. If the water is choppy, the reflection is broken and unrecognizable. If the water is still, the reflection is very clear. Yet, as alluring as that image may be, it is still not the moon.

If you have never read the manifesto or haven’t in a while, do it now. Really. Go. I’ll wait. It’ll only take a minute.

Back? Great.

One of the values is “Working software over comprehensive documentation”. It doesn’t say don’t create documentation, but place a higher priority on working software over comprehensive documentation. Focus your priority on creating something that works more than an exhaustive description of something to build. Make sure that the documentation the team chooses to create has lasting benefit.

The values are not absolutes, but relative statements. If you adopt practices associated with agile without understanding the conceptual underpinnings, you may find that you are not getting the effect you hoped for, or maybe there are better practices that would support those values better given the unique situation of your team. A team that adopts the practices without incorporating the principles will be like like the moon’s reflection on choppy waters. It will be tough to see a coherent vision of what is being done. A team that chooses its activities based on how the values fit them will be like the reflection in a still pond.

For me, one of the most evocative parts of the manifesto is the last principle, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” That alone, is worth the price of admission.

Please take a moment to rate this post (under the title) and leave your comments. Which elements of the manifesto does your team most embody?

Do Disruptive Startups Need UX?

According to Clayton Christensen in The Innovator’s Dilemma, markets for disruptive technologies may not be known prior to release and therefore often cannot be planned for. Where does that leave UX? How can you do research if you don’t know who to talk to? How can we do any user-centered design if we don’t know who the users will turn out to be and how they may use the product? So what is the value of UX in an early stage start up or similarly innovative team?

While he doesn’t say so explicitly, his research seems to favor an agile approach. Constantly evaluating  the product to determine who is using it and what value they are deriving will allow a team to focus their efforts on the goals most important to this new found audience.

This points to two clear uses for UX in the early stages of the creation of a disruptive technology. The first is to give the product the best chance of success by inc0rporating design standards and best practices. The second is in researching the new population of users, their activities, goals, and behaviors.

You only get one chance to make a first impression. Leveraging interaction standards will help give a new product the best chance for a positive initial reaction. Design standards may not work for everyone. They are, by definition, generic. However, it will make the product most likely to be usable by the broadest possible audience. In addition, while aiming for ‘just barely good enough,’ make sure that there is a shared definition of the level of quality required and that there is a UX component to that definition.

Once the first release is live, analyze the user activity. Reach out to some of the most active users. Talk to them about what they love, what they don’t like, how they found out about you, etc. Keep probing each answer for more detail. Find some users who signed up but never became active. What made them interested initially? How did they find using the product? Why did they stop? See if you can define the gap that prevented them from becoming active users.

Once similar stories of real people deriving real value begin to emerge, then we can start to leverage familiar UX tools to move beyond best practices to create a tool that supports the unique needs of those using it.

Having UX involved from the beginning will help you recognize the market when it emerges and be ready to meet its unique demands.

Share your experiences designing new or disruptive technologies. When was UX involved? While you’re at it, please rate this post using the stars beneath the title.