Category: Agile


Tim Cook on Collaboration and Innovation

December 13th, 2012 — 10:24am

A colleague sent me the Business Week interview of Tim Cook yesterday. I also just finished reading Isaacson’s bio of Job, which was a fascinating history of silicon valley, and insight into the creativity and rigor at Apple.

The Cook interview was a nice follow-on to the bio, and interesting to see how Apple has defined its culture and mission. This also follows closely some of my recent posts about team collaboration.

A few quotations that stood out to me…

The key in the change that you’re referencing is my deep belief that collaboration is essential for innovation—and I didn’t just start believing that. I’ve always believed that. It’s always been a core belief at Apple.

“Oh my God. How could one company do all of this?” And it’s not like we have that many people. As a matter of fact, that’s a secret. You know, small teams do amazing things together.

Customers want iOS and Mac OS X to work together seamlessly, not to be the same, but to work together seamlessly.

The most important things in life, whether they’re personal or professional, are decided on intuition. I think you can have a lot of information and data feeding that intuition. You can do a lot of analysis. You can do lots of things that are quantitative in nature. But at the end of it, the things that are most important are always gut calls.

Creativity is not a process, right? It’s people who care enough to keep thinking about something until they find the simplest way to do it. They keep thinking about something until they find the best way to do it. It’s caring enough to call the person who works over in this other area, because you think the two of you can do something fantastic that hasn’t been thought of before. It’s providing an environment where that feeds off each other and grows.

Comment » | Agile, Innovation

Agile in the midst of big growth

November 30th, 2012 — 10:59pm

Spotify has done such an amazing job creating an lean, innovative culture and fostering communication while increasing headcount 10x or so.

http://techcrunch.com/2012/11/17/heres-how-spotify-scales-up-and-stays-agile-it-runs-squads-like-lean-startups/

“But they also point out that in the regular surveys they carry out — also part of the agile working process — they have found that “Despite the fast growth [of Spotify] employee satisfaction has continuously increased; in April 2012 it was 4.4 out of 5.”

Comment » | Agile

Lean UX is about communication

November 25th, 2012 — 11:33pm

There are few articles linked below on Agile & UX that I really love. The common theme between them is the replacement of documentation (PRD, Func Spec) with team communication. Teams develop a shared understanding as they work together. The user’s voice is championed by UX but because other disciplines are involved from the start leaps can be made in how a feature or workflow is built, usually more technically sound with better quality.

In The new user story backlog is a map Jeff Patten describes how story mapping creates momentum for the team and is the basis for presenting the fundamental direction to the team. The team works together to understand the problem and user goals and plans what needs to be done first to be able to create a minimum viable product that can be tested.

In “Lean UX: Getting out of the Deliverables Business” Jeff Gothelf describes how UX Designers can lead the charge, and work with the scrum team, to create better results and software than could have been done otherwise.

Comment » | Agile, User Experience

My experience with UX and Agile

November 13th, 2012 — 11:15pm

Recently I’ve been considering how I would help other user experience designers work with the my product team as collaboratively as I have for the past two and a half years…what do I do?…how have I been successful? The feedback I’ve gotten is that I’m an integrated part of the team – appreciated by the engineers I work with almost to the point of relief. This means that I work with the team to make decisions daily. Ideally these decisions are informed by domain knowledge, and/or by direct user feedback. Design decisions have to be grounded in the product, division goals, and practical considerations of current and future state of technology. Not every decision can be researched, and designers have to trust their instincts as designers and their knowledge/history on products and workflows to make decisions.

During the course of our most recent release, I set up continual research with a set of senior stakeholder users that I consider product advisors. These users tend to be evangelists, or could be so, in their companies and want to work in 3d and understand the potential of modeling large scale infrastructure projects in 3d. Continual research means ongoing meetings, either one or two sessions per month with ten or so users. This roughly equates to 3 – 4 hours of informal interviews per week to discuss requirements, review design concepts, and to perform usability audits of prototypes.  Conducting continual research is hard, but keeping it informal makes it manageable, and keeps me in touch with how our key customers are using the product currently and where there are gaps in the workflows they hope for, and provides a mechanism for concept direction and design validation.

Knowing the medium I work in has also been a critical component, and allows me to create the best interaction model within the current state of the technology….handing Van Gogh a stone block and a chisel would would have perplexed him, because its not the medium he knew and he would likely have struggled.

Let’s break this down…

What does it mean to be an integrated part of the team?

  • You are not the defacto expert, and you don’t need to be
  • Start with the assumption that software engineers, QA engineers, product managers (and others stakeholders) have addressed detailed problems in the domain and have a deep understanding, and therefore are a source of input
  • Make decisions on the fly with the team on a day in and day about basis. If you’ve done research you tend to lead the discussion
  • Don’t be afraid to fail. Agile means you can correct mistakes
  • You are an interaction designer making software. You are not a mock-up designer producing documents. Testing early mockup is great for validating design concepts and design direction but fails terribly for testing interaction design.
  • Testing working end-of-iteration prototypes makes you a better UX designer.

But making design part of the scrum team means I’m losing authority as a designer….

  • This could not be further from the case
  • Believe it or not, engineers want the best experience, set of workflows and features for the user as possible
  • Talking to users continually means you understand how they think
  • Engineering will look to you as the lead in making decisions on the scrum team because of your thinking and the discussions you’ve had with users….
  • Because the nature of agile means breaking down stories to atomic levels, it is up to UX (and product managers/product owners) to make sure the big picture is not lost when piecing together user stories back up to the epic and theme level

Comment » | Agile, User Experience

Back to top