Eric Burd: Want to win with Agile? Pivot your culture.
- If you don’t have everyone on board, you have a problem.
- How do you get the business side on board with lean/agile?
- How do you set expectations on Minimum Viable Product?
- Focus on one clear end goal, and try different ways of getting to that goal; “Keep one foot on Everest”
- Two groups to win over:
- Dev Team: they’re the ones who “get it.”
- Sales, Marketing, Ops people
- Many articles, books, etc. focus on winning over the tech and product teams; who’s talking about winning over the rest of the business team?
- Agile isn’t as much about mitigating the tech risk; it’s about mitigating the market risk—building something nobody wants.
- The business side believes that WATERFALL is about risk mitigation
- clear beginning, middle and end
- “campaigns” and “budgets” — long term thinking
- We can’t get these sides of the business (marketing, ops, finance) into an Agile process, but we can do better at informing them of what we’re up to.
- Six tips:
- Find or light a “fire:” tie it to another issue within the organization (e.g. morale of dev team)
- Listen to the customers; by being user-centric in our thinking, we can build better products. HOWEVER, you can’t get execs to actually listen to focus groups or usability labs. What you can do is bring customers in to have “lunch” with the executives, and customers can help sell execs on the process.
- Get sales team in on it. Hearing from sales (i.e. people who regularly talk to customers and are trained at knocking down objections) that the process will help the org can make great strides towards getting the rest of the team on board. If the sales team can start hearing that customers are having product-driven issues that you can fix with Agile/Lean, you’re halfway there.
- Words matter. When we’re using jargon, being self-referential, we’re essentially talking to ourselves. Other folks don’t get it. Start learning the language of the people you’re trying to sell to.
- Train the exec team.
- Focus on small wins. Find small wins within the org, and attach those to agile/lean vs. focusing on a “big bang.”
Phin Barnes: Investing in Design
- The building blocks of the web are getting bigger and bigger, and easier to manipulate by clumsier and clumsier hands.
- modern languages (PHP, Ruby, etc)
- cloud services
- ability to code and test relatively quickly
- The web has returned to the basics of customer development; design must follow. Four stages:
- Problem Definition
- Sketch or Prototype
- Improve Solutions
- Implement Best Solution
- Mindset > Skill set
- No Unicorns and No A**holes: avoid the person who “knows everything” and doesn’t listen
- Someone who listens and pivots improves over time
- Someone who develops a “vision” and argues for it won’t listen to feedback; won’t listen to data.
- Avoid making multiple minor iterations on the same bad vision.
- Look at the feedback loop process
- It’s easy to fake some of these things, i.e. talk the talk
- If there’s one place where craft really counts, it’s in the feedback process
- avoid comments that don’t move the project forward, or aren’t actionable
- Feedback = an effort to understand where the person who created the feedback was coming from
- Great feedback sessions are:
- Planned out, in terms of what you want from the session
- Organized in terms of decision points, and problem statements: what are you expecting to solve? What are you expecting the user to do here?
- Watch people using the product, and videotape them; discuss it with the product team
- What moves the crowd at your company?
- Data, or a “visionary unicorn?”
- At the best orgs, qualitative and quantitative data work together.
- What are you measuring within your company?
- If you’re going to adopt a design mindset, it has to be full staff
- Get the rest of the org on board.
- Make it tangible; find ways to get folks into the process and want to contribute to the product.
Josh Seiden: Replacing Requirements with Hypothesis
- @jseiden; proof-nyc.com
- Requirements and Hypotheses can both be used to frame the work of teams.
- REQUIREMENTS: create an Internet Mouse that people can use when surfing the internet on their TV from their couch.
- HYPOTHESIS: I think people will pay for a device that makes it easier to surf the internet from their couch, and you need to figure out what that might be.
- For most teams, HYPOTHESES are a more effective way to manage your workload.
- It’s very rare that you’re working in a condition of certainty, hypotheses let you operate in uncertainty.
- Requirements take the THINKING out of implementation; team has no visibility to user/market needs.
- When you give a team a problem, you engage the team’s creativity.
- But you also need to give the creativity some boundaries, to keep moving the team forward
- When you are building to an established standard, use requirements; if you’re creating something NEW, use hypotheses.
- Hypothesis = Answer posed as a question; sets up an assumption to be tested.
- Every design decision is a hypothesis that the market will test for you. If you can reduce the time between the design decision and the market feedback, you can drastically reduce risk.
- Format of a hypothesis
- Statement of what you believe to be true: We believe that…
- A statement about how you’ll validate the hypothesis: We’ll know we’re right when…
- Example: We believe that people will pay for a device that makes it easier to surf the internet from their living room couches and we’ll know we’re right when people can use our mockups without trouble and when people offer to pay for what we’ve built.
- Identify assumptions
- What assumptions do you have about your customers?
- That if proven wrong, will cause you to fail?
- Who are they?
- How does this product fit into their work or life?
- What problem does it solve?
- When and how is it used?
- Express as hypothesis
- Test riskiest assumptions FIRST
- What are the highest risk assumptions that we know the least about? Put those into a backlog.
- Break them down into testable parts
- Use MVP concept to test your hypothesis
- What is the smallest thing we can create to test our hypothesis?
- Get out of the building: watch people to get feedback.
- Lather, Rinse, Repeat
- Use story maps to get all your requirements on one wall
- Story Maps: check out “Agile Product Design” site (http://www.agileproductdesign.com/)
- Identify the risk points in the story map
- Turn those risks into your hypotheses
- Find your metrics, and map your hypotheses against those metrics (e.g. product funnels)
As I may have mentioned on this here blog (but also have been oddly quiet about), this summer is a Writing Summer. I’m in the middle of writing Drupal for Designers, a series of guides for O’Reilly geared towards designers who want to work with Drupal but don’t need yet another recipe book telling you how to download a module. It’s a great project, and one that I’m psyched to be doing. But I am noticing that the experience of writing a book, from a project management standpoint, is far different from the experience of creating a website.
In some ways, it’s remarkably similar to what I do in my consulting/UX work. There’s a huge amount of research, and user interviews (I’ve done about 12 interviews thus far, and still haven’t talked to all the people I want to), and the book is basically the result of that research and interviews. But I’m still working on the flow of writing; getting to that state where I can accept that writing and research is what I do all day.
This is, I think, a problem of being self-employed for as long as I have been. I get so accustomed to wearing several hats that wearing any one of them for too long feels foreign. While this is a pattern I’m looking to change in the future, once I find the right team, I imagine that there’s still a bit of unlearning I have to do in order to feel truly comfortable focusing my attention exclusively on the aspects of my job that I love. The temptation to retreat back into code and implementation – which is often easier, but less interesting to me – still catches up to me now and again.
None of this is really a complaint, per se. But it is an observation that being a writer seems to have a different character, and a different set of requirements, than being a site builder or a coder. Because writing is something I love doing, it almost feels like I’m taking a break; I couldn’t possibly be doing this because I’m paid for it, or because it’s my job. This is what I’ve always done just to get things off my chest, or to share information that I’ve learned. Having it as my job, at least temporarily, almost makes me feel like I’ve been given a free ride to goof off. So while I’m making headway on the book day by day, I almost feel guilty having to step away from code and clients for a few hours a day.
And then I remember that there’s a book deadline looming, and I have a lot of research to compile, and I get back to it.
So many things to say about being in Prague. For one thing, I’m delighted at the amount of international travel I’ve been able to do this year. Between the honeymoon last year, this trip, and a potential trip to London in August (should one of my sessions at Drupalcon be selected, various appendages crossed), I’m feeling positively European.
- We discovered that, in Prague, there seems to be such a thing as a Tourist Dungeon. At least, that’s what we’re calling it. The first night here (after we fell asleep for several hours due to OMGJETLAGWTF) we went to a brew pub called Pivovarsky Düm. Excellent beer, okay food, but the service – well, let’s just say that once the host realized we were tourists, we were very politely pointed to the basement, where we were delivered English menus. This, after being told off by a waitress and the bartender for asking if we could grab a beer while we waited for a table. Fortunately, this hasn’t been my experience with every place we’ve been, but it was still uncomfortable for our first time in the city.
- Why did we stay, you might be thinking? BEER. Delightful, unfiltered, wonderful beer. The fruit beers were not really my thing, but I will say that they were the best of the genre I’ve tried. My favorites were Coffee beer (OH MY GOD GOOD), and Nettle beer – which was green, with a very herbal thing going on. If they had it in the US I’d buy it by the case. It’s a much better St. Patty’s Day alternative than the Budweiser with green food coloring we serve in bars around Boston. Nick tried a Wheat beer that, speaking as a Harpoon UFO fan, absolutely blew UFO out of the water. It was fresh, lemony, and the best of the bunch that we sampled.
- Speaking of Budweiser, apparently it’s also the name of a Czech beer that’s entirely different from Budweiser, but has exactly the same logo. Our hotel, in fact, serves it.
- I have decided that there are entirely too few sandwiches that involve sliced hardboiled egg. Part of this was decided based on Clover’s Eggplant and Egg sandwich (one of my favorite things). But in the Amsterdam airport, I was delighted by a sliced egg and bacon sandwich, and there’s a deli near our hotel that serves slices of bread with sliced egg, a bit of cucumber, tomato or pepper, a slice of ham and pickle. It is the most wonderful thing ever. I have a feeling I just found my new summer staple meal.
- I’ve also learned, thanks to a Drupal buddy of mine, who introduced me to a local Drupal designer, that there’s a Coworking space less than a mile from my hotel! I plan on heading over there on Wednesday to work for the day, and I’ll be heading to a Drupal meetup that evening – which will likely be all in Czech. I’m fascinated to see how that works out for me (I know very little Czech).
- Most things here are surprisingly cheap. The best, though, was massage – through the hotel, I got an hour-long, and desperately needed, massage for about $60 American, which included tip. I can’t tell you how much I needed that – I can, however, say definitively that it will be happening again on Thursday.
And, just a touch of snark:
- I didn’t realize until I came to Prague exactly how much Rhianna or Celine Dion I could listen to in a sitting. Thanks to the hotel, and the local coffee shop, I’ve learned that the answer is “quite a bit.” I’d like to unlearn that.
I’m trying to view Prague as both a bit of a much-needed vacation and a writing expedition. The first draft of the project management guide for The Designer’s Guide to Drupal is due on June 1st, and I’m much further along in writing than I am willing to believe I am. It’s interesting, once you start getting things down on paper, both how much you actually know and how little you *think* you know. No matter how much material you have, it never quite feels like enough. Fortunately, things are going along pretty well, and this trip offers a good opportunity not only to get out of my normal way-too-busy schedule, and organize the vast amounts of research I’ve been collecting into something cohesive for the publisher.
What’s been delighting you lately?
I’ve been quiet on the blog (and my professional site, the zen kitchen) for the better part of four months now. There’s many reasons for that, mostly to do with being insanely busy, but also to do with a change in professional direction towards more of a UX research and design practice and less of a soup-to-nuts branding and design firm for smaller businesses.
To that end, a couple of changes have taken place:
- In January, I contributed several chapters on design and Drupal foundations for the Definitive Guide to Drupal 7, which is being released sometime in the imminent future (so I’m told) by Apress.
- I just wrapped up one of the most challenging projects of my career – working on a team doing UX and prototyping for a site redesign that will be launched later this year. The project (and my contributions to the Apress book) gave me a huge opportunity to get over some enormous learning curves with Drupal 7 (not to mention UX deliverables and working on multidisciplinary teams), and I can’t wait to do more of it.
Speaking of getting over Drupal 7 learning curves, I’m also in the process of writing a series of books for O’Reilly Media, tentatively titled Drupal for Designers. The series is intended to provide a designer-friendly guide to working with Drupal, estimating and planning projects, managing client relationships, and all the other knowledge I’ve collected over 6+ years of running my own design studio. It’ll be released online a bit later this year, with a print edition (hopefully) planned for 2012 sometime.
In the meantime, I’m still open to new opportunities. If you know of a great team looking for some UX love, drop me a line anytime.
Note: This is the twenty-seventh in a month-long exercise called Reverb10, where bloggers reflect on the year before and think towards the year ahead. The idea is to post daily, based on the day’s prompts; let’s see how well I do.
Prompt: Achieve. What’s the thing you most want to achieve next year? How do you imagine you’ll feel when you get it? Free? Happy? Complete? Blissful? Write that feeling down. Then, brainstorm 10 things you can do, or 10 new thoughts you can think, in order to experience that feeling today.
There’s much in this prompt that I plan on answering in my personal journal, but not here. What I will say is this:
I’m ready to find a full time position with a team that’s doing some really cool stuff. Specifically, I’m looking for a high-level position in UX Design/Strategy, Art Direction or Design Strategy that will let me focus on solving interesting problems alongside a great team, and less on running a business day to day. While I love running a business, and some would say that entrepreneurship is in my blood (case in point: I launched a new side business during my job search), I want to find an environment where I can learn from people who are better than me.
That’s what I plan on achieving this year. Along with getting closer to my degree, and moving towards a Master’s. And it’s going to feel really damn good when it happens.