Agile2013

How do you know you're developing the right product? This talk will help you think creatively about how to do customer development using Agile and Lean User Experience methods. I'll share what we learnt about using rapid, iterative prototyping techniques to develop a minimum viable product at a software conference.

In August 2012 we attended Kscope, a conference for Oracle developers. Instead of doing the usual product demonstrations, we turned our stand into a live lab and took Agile development processes out of the office and in front of our customers. Our stand included an area for customer research, a Kanban board and information radiators in the form of a whiteboard, blank wall and a large digital screen. Over 3 days we ran 9 sprints and conducted 25 customer interviews, using a paper prototype to get feedback. We collected invaluable information about our customers' development environments, how they work with their teams, their processes, tasks and pain points. By the end of the conference my colleague had developed an interactive HTML/CSS prototype which potential customers could evaluate. The team went through several rapid build-measure-learn cycles to improve our product concept and validate the market need.

I’ll cover the benefits and pitfalls of doing live design and development in front of potential customers and competitors. For example:

• doing guerilla research with no up-front participant recruitment;

• analysing and making sense of large amounts of research data on the fly;

• making your design and development process transparent;

• recording and communicating research insights for future reference and remote team members.

The talk will illustrate how opening up our development process at a trade show provided visitors to the stand with an opportunity to experience Agile and Lean methods first-hand, and that marketing teams can learn a lot from Agile development teams.

Anyone directly involved in product design, development and marketing would get value from attendi

How to improve Agile Development?
Where are the users on the Agile Development Manifesto?
How is Agile related to Lean?
How users can help avoiding waste?

or even more:
How can everyone become involved in the customer research process?
How can you use UX to drive innovation within large enterprises?

These and other questions are going to be discussed on this talk that was created after years of experience working for enterprises and startups together. How they can learn from each other? That is what Alline Watkins found about Lean Startup and Agile Development.

In this talk the presenter will show the User Driven Development Process in details and how this process can improve Agile Development. The UDD process was invented by Alline Watkins while working at a 100% Scrum project at Nike Inc. and put together in the blog below:
http://UserDrivenDev.com

Many people think of branding as logos and colors. But, there's more to this branding thing than you may realize. *Every encounter a customer has with your product is a brand impression*. Understanding and applying brand will always make your product more successful.

Maybe you've noticed brand and marketing managers don't seem to get Agile. Perhaps you view branding as an annoying, superficial requirement pushed on you by managers who don't understand rapid development.

I'm a design craftsman with a marketing background working at an Agile shop. In agile software development, my observation has been that the full benefits of branding are often not considered and sometimes even ignored. From my experience as a designer in an agile world, I can assure you brands can *AND* do actually benefit from the agile process.

I'll be sharing three real-world product stories that illustrate how agile development works with brand:

* **A mom and pop startup** - How we discovered and built the right brand for the product, embracing change along the way.
* **A stand-alone application for an existing brand** - How we iterated and evolved the brand as we continually tested it with real customers.
* **A data-driven application for a large regional company** - How we worked with the organization's marketing management team to push the brand into new territory with a digital product.

You'll see how I applied brands through iterating, listening to customers, working with business people, attention to good design, reflection, simplicity and embracing changing requirements.

A company's brand — and how it's applied — is *THE* differentiating factor in products. As developers, designers and product managers, let's work together to make the most of it in our applications.

Large companies tend to have strictly-enforced and heavy processes, which make them slow moving and generally a place where it is hard to innovate.
IBM has long been an engineer-led organization, where UX to engineer ratios are still be very low in some teams, and where UX best practices don't always see the light of day.
But IBM has just started to undergo the largest cultural shift in software history (400,000 people large!), it's the beginning of a new era at IBM, the era of Design Thinking, and it's led by the new General Manager of Design, Phil Gilbert (yes, you read it correctly, a GM of Design!) [1] [2].

In this talk, I'd like to share the key components of this amazing transformation that IBM is undergoing, with Lean UX and Design Thinking leading the way.
Design Thinking [3] encompasses the thoughtful design of any kind of user interaction and experience that user has with your system, from the installer (5 clicks instead of 20 would be nice), to the API and, naturally, the user interface.

At IBM, rather than trying to dictate great outcomes via specific processes, the IBM Design Thinking initiative introduces a framework that provides the freedom to act in a very lean and agile way. It proposes a new[4] way of thinking and advocates for clear conceptual models and decisions, including an MVP approach to scoping (Minimal Viable Product) with no more than 3 main business objectives per release, strong involvement of sponsor clients throughout the development cycle, shared product ownership by the Product Manager and the UX or Design lead, iterative approach to releases and regular demos to all stakeholders.

[1] http://redmonk.com/jgovernor/2013/01/07/on-the-importance-of-design-at-ibm-love-and-margins/

[2] http://blogs.forrester.com/clay_richardson/12-12-17-design_thinking_blurs_the_line_between_process_and_experience_design

[3] Wikipedia: As a style of thinking, design thinking is generally considered the ability to combine empathy for the context of a problem, creativity in the genera

If you are building software for people who are not developers, there is a good chance that you are making bad assumptions about their goals, needs, knowledge and skills. And if you don't know what will work for your users, you can't build working software.

Doing user research before and during development helps inform your choices about strategy (what to build) as well as tactics (how to build it)-- and it doesn't have to slow down your development process . In fact some rapidly executed research can speed up your time to market by reducing the need to refactor late in a project.

This presentation will provide practical information that will help product owners and developers quickly get inside the heads of their users, validate product ideas and improve the usability of their software at warp speed. The presenters will share tips and techniques for recruiting research participants, shadowing and interviewing users effectively, getting valuable feedback on product concepts and information architecture, and rapidly iterating on the user interface to improve usability. They will demonstrate remote testing tools that will help teams rapidly identify effective information architecture and labels and test users can successfully achieve their goals with their designs., and cover best practices for live testing and collecting feedback from users after launch.

Solutions are the death of a product design. Learn how Tami Evnin helped to disrupt a large, product-focused organization with design, through not only educating product owners, but including them in the exploration to define problems instead of solutions.

A small but growing internal design team within a large product-focused organization has had a strong voice in the development process of our company’s client-facing products. As with any change in process, growing pains were inevitable. Instead of making cosmetic changes to old, unvetted solutions, we challenged our team to find problems that needed solving in order to create a better overall product. We introduced research methods, design studio, and rapid prototyping into our colleagues’ vocabularies early and often. Even through a series of discouraging review sessions and a multitude of poorly worded email critiques, our team came to trust and understand that our design strategy got us to the heart of our users’ needs.

I will talk *process* - the team, communication, and validating big questions and ideas; *failures* - mismanaged agile processes and unactionable critique; and *how we are moving onward and upward* - team sketching sessions and other design studio methods, communication improvements, and productive sprint planning.

There's a dirty secret in the turf war between agile, lean, and waterfall: they each use the same product development process. What's different isn't their process, but how they apply design activities in different ways to eke out design value in different places.

So how can you alter the design process? Even better, how can you best customize the process to provide more value for the way your organization works? More importantly, how should you change the design process from sprint to sprint to get the most value out of your design activities?

How do you hack user experience?

There are five levers you can tweak to adjust how you get value out of the design process:

* audience
* fidelity
* annotation
* communication
* velocity

For each of these levers, we'll examine how they inter-relate, how they govern the value you can get from design activities, and the issues and questions you should consider when hacking the user experience process.

This talk won't be about nifty methods or collaboration or white boards or prototypes. When we're done, you will leave with a toolbox for continually hacking the design process. You'll understand why some nifty methods work for others and not for you. You'll understand how to hack your own nifty methods that will work best for your team. And most of all, you'll learn how to teach everyone on your team how to hack the design process.