Tag Archives: value

From Sketch to Code

One of the issues often discussed regarding the integration of UX and agile is the amount of UX documentation that is appropriate. There are many who recognize the value of a little, or sometimes a lot, of upfront design, while others see it as waste. The answer is less ‘or’ than ‘and’. Clearly a design by itself delivers no value until it is built and delivered, and no one in their right mind would challenge the necessity of software engineers. Most projects could also benefit from some amount of thinking prior to coding. The challenge for each team is to be constantly searching for the right balance for their team, in the current sprint, working on a given story.

Two Ends of the Spectrum

I think that most would agree that when a concept is in its infancy and the rate of change is high, it is more effective to iterate through the designs in a lightweight way, without code. Despite how easy it is to quickly generate working prototypes, it is still not as fast as some of the most lightweight design tools, like whiteboard, paper, napkin sketch, or even wild gesticulating. When ideas are vague, there is no consensus on the basic direction, and the impacts are not well understood, it is far more effective to work collaboratively with stakeholders on low fidelity sketches than to create interactive prototypes followed by group reviews.
On the other end of the spectrum, it is far more effective to make small changes directly to the code, and, if possible, forgo the overhead of continuously updating the design documents. At this point, when the design has solidified, stakeholders agree on the vision, and the rate of change is small, let the finished work speak for itself as much as possible. Only update documents to describe complexities that would not be obvious by looking at the finished product.
In the middle are steps that might include one or more of the following; refined wireframes, light ‘throw away’ prototypes, graphical comps, or even detailed specs.
The logical question is when to transition the design to code. Like many agile questions, there isn’t a single answer, but here is one way to think about the question to find an answer that will make sense for you.

Put Another Way

It design time is D and subsequent coding time is C1, and code and revision without any upfront design is C2, then the goal is for D + C1 < C2 AND the output of C1 is ‘better’ than the output of C2. If you don’t agree with this goal or don’t believe it is possible then I probably need to convince you of the value of UX to agile (post coming soon).
If D + C1 > C2, then it must be offset by an even greater improvement in quality of C1 over C2. (Thanks to Adam Sroka for inspiring the mathematical representation)
Keep in mind, what makes sense for one team/sprint/feature combination may not work for another. There have been instances where I’ve sat with a developer an said something like, “Take this widget from this page and add it to this page over here and make it look like the other widgets on that page.” No wireframe. No document of any kind. One developer and one UX’er sitting together knocked it out in under 20 minutes, iterating as we went. There have also been complex interactions with impacts throughout the product that required more extensive exploration before the design stabilized enough that development felt comfortable proceeding. It wasn’t unusual to have both of these kinds of stories in the same sprint.

The Bottom Line

The reality is that you never get to do the same story with the same team in the same context twice, so there is no way to measure the difference. Ultimately, it comes down to a judgement call between the developer and the UX’er.
UX needs to be willing to abandon the design document before the design is complete and collaborate directly with a developer on it’s evolution, and developers need to be willing to take a step back and explore what they will build before writing to much code.
How well does UX and dev work together in your team? Please share your thoughts on this post in the comments and take a moment and rate this post using the stars beneath the title.

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?

When Adding Waste isn’t Waste

Naresh Jain over at Managed Chaos was griping about The Bloat Effect. The gist is that as time moves on, everything gets bigger and more bloated, including the software, the team, and the process. This makes everything less valuable as a result.

There is often waste in our process. Sometimes it’s given to us and we have to deal with it. Occasionally we introduce it willingly. Often, we start out bloated. We may have an idea of what the streamlined, efficient process looks like, but it’s not what we adopt. Often there are good reasons, or at least reasons. We are, after all, smart, intentional people.

First of all, a definition of waste. Anything that does not directly add value to the customer is waste. Anything that causes you to spend more time than is necessary, is waste. Anything built but not used is waste. Anything that hinders progress is waste. A common goal of any process is to minimize waste, but sometimes we need it. Sometimes waste in the micro saves work in the macro. Waterfall is kinda like this. The theory is that the more you can remove uncertainty with upfront work, the smoother the project will be, ultimately saving time than if the project had tripped over some of the intricacies later in the cycle, or at least having predictable results with predictable resources. Of course, we know how well that usually works out. Agile aims to minimize all of this waste through multiple iterations and is comfortable with whatever revisions may be necessary later on, based on what we learn.

Recognize the role that waste is playing.

If you are being asked to do something you consider unnecessary, find out what need it is filling. If there isn’t one, you may have an argument for eliminating the task. If there is, you may be able to find a leaner way to solve that need. If you don’t have the authority to make the change, you may have to figure out who in the organization can and convince them. Unfortunately, waste is often thrust upon us with no recourse. Then it’s back to a software version of the serenity prayer, accepting what we can’t change and working on what we can. Sometimes that’s just just ‘how it’s done’.

However, you may choose to add steps into your own process to save time later on. If you experience a frequent roadblock that causes a lot of churn, you may need to add extra steps upfront to deal with it. For example, if you have difficulty communicating new concepts to key stakeholders, perhaps more time needs to be spent fleshing out those ideas before they are presented, especially if you believe that they are justified by the business and user needs. Do you spend time that feels unnecessary? What steps could you take earlier to minimize this unnecessary expenditure of effort? Would the trade-off be worth it?

Simplify as you go

Even if you can’t immediately change the process, you can work to simplify over time. Just because there may be legitimate reasons why you live with the excess now, don’t let that keep you from working to improve the process. This is one of the 12 principles of behind the Agile Manifesto. Can you take a small step the next sprint, or the next release, to streamline? Can you keep educating those insisting on inefficient methods in better processes? Is it waste or is it really saving you time later on? People may be hanging on to tools and processes that they are familiar and comfortable with. Moving them away from them too quickly may be difficult or undesirable in the short term. As you demonstrate success, you will have the freedom and trust to make changes and put past process attachments to rest.

Is it Agile?

As you evolve as a team, you may encounter people who tell you that, ‘You’re not Agile.’ They may be right. You may not be capital-A Agile, but I think the key questions are:

1. Are we doing better this sprint than last sprint?
2. Are we making changes that we expect will enable us to perform better in the next sprint?

Adding value

To often I’m concerned less with removing steps than with adding them. It seems common to encounter an engineering team that has been using agile without the benefit of UX and now they are experiencing some pain. There is often the misconception that waste is anything that is not working code. At the recent Deep Agile Conference, James Coplien indicated that, “Rework in implementation is waste, rework in design is agile.” Adding in a quick usability test to uncover design flaws early is not an outdated process to be slowly abandoned. It is a positive practice that should be introduced where it is lacking. Engage with your users, gather feedback on your product/designs, measure your results. These are steps that do not directly contribute to customer value, but they are some key elements that form the foundation of a solid product. Waste needs to be looked at in the context of the entire product, not just the tasks that any one individual or team are performing.