Re: [agile-usability] Agile & UX - interview with VP of Engineering at Mindflash
- Awesome statement:
"I think it was because releasing that frequently and working so closely with people who eagerly studied the impact of their work got them similarly interested. Rather than being builders of arbitrary stuff, they were active participants in having an impact on the world."
This is why I care so much about UX, but it seems William and I have very different opinions from many on this list. The value in programming, testing, and UX is in having an impact on the world. The sooner you understand and the better you can measure that impact is THE REASON why short cycles, tight collaboration and speed trump long cycles, silos of UX/dev/test, and long release cycles.
Great to hear about You Tube's process. Big names have lots of influence.
Robin Dymond, CST
Managing Partner, Innovel, LLC.
Americas: (804) 239-4329
Europe: +32 489 674 366
On Wed, Feb 23, 2011 at 11:44 AM, William Pietri <william@...> wrote:
Hi, Jon! Excellent question. They were indeed adding value.
A big reason they were releasing daily was that the product managers were very interested in whether their improvements actually delivered value to users and to the business. The sooner something was out, the sooner they could start getting data on what it did (or didn't do) for users. Their A/B test dashboard, all built locally, was fantastic.
The day I went by they had an all-company meeting (which was maybe 40 people) to present a major improvement in their ability to get user feedback and longitudinal metrics. At a lot of places that'd be a snooze for developers, but that wasn't true there. I think it was because releasing that frequently and working so closely with people who eagerly studied the impact of their work got them similarly interested. Rather than being builders of arbitrary stuff, they were active participants in having an impact on the world.
On 02/22/2011 05:00 PM, Jon Innes wrote:I'd have to ask if they were moving the needle on adding value to customers working at that rate, or just doing a bunch of stuff to feel really busy.If they could actually create measurable value at a release a day, while maintaining quality, and not incurring technical or UX debt, then I'd like to invest in them!JonOn Feb 22, 2011, at 2:21 PM, William Pietri wrote:
On 02/22/2011 09:52 AM, Austin Govella wrote:
On Sun, Feb 20, 2011 at 4:23 AM, Robin Dymond <robin.dymond@...> wrote:
In my opinion 1 month sprints are too long.[...]
It's only too long if you don't do three full days of RITE testing two weeks in. The planning is easy: do less. One week to collaboratively design the system. One week for people to build their pieces. One week to RITE test, and one week to finish bugs. It's breezy, low-stress, high-quality, and everything gets done. Very few tasks slip. If you're fear is that too much can change, then you're moving too quickly. If you don't have a couple of months to build, launch, and measure a feature, then that feature isn't worthwhile. Why are you building it?
You should naturally work however you please, but I read the last paragraph as suggesting other ways of working are ridiculous to you, which is faintly insulting. Also, your conflation of cost and value is disappointing.
I visited one very successful team that was doing daily releases and brought me in to figure out how to release more often. At the time of my visit, they had circa 30 ongoing experiments. Some would last days, some months. Rather than spending 1 week of 4 getting data, they did it every week. Even going back to weekly iterations would have been a severe blow to the product managers and designers.
I like the spirit of the RITE method in that it clearly recognizes that shorter feedback loops lead to faster learning. But it's exactly that insight that has pushed me to shift first to weekly iterations and then to a clockless, kanban-style process.
I should also add that any team that needs to spend 1 week taking out bugs that they spent the last 3 weeks creating probably has a lot of opportunity to improve productivity though quality-focused technical practices.