8. @lishubert Agile’s Secret Step: Discovery May 14, 2011
9. @lishubert Agile’s Secret Step: Discovery May 14, 2011
10. @lishubert Agile’s Secret Step: Discovery May 14, 2011
11. @lishubert Agile’s Secret Step: Discovery May 14, 2011
12. Agile is a
DEVELOPMENT
methodology...
@lishubert Agile’s Secret Step: Discovery May 14, 2011
13. Agile is a
DEVELOPMENT
methodology...
but WHAT are we
developing?
@lishubert Agile’s Secret Step: Discovery May 14, 2011
14. @lishubert Agile’s Secret Step: Discovery May 14, 2011
15. @lishubert Agile’s Secret Step: Discovery May 14, 2011
16. Agile...
is NOT
the enemy
@lishubert Agile’s Secret Step: Discovery May 14, 2011
17. How do we get here?
Agile
UX
@lishubert Agile’s Secret Step: Discovery May 14, 2011
18. @lishubert Agile’s Secret Step: Discovery May 14, 2011
19. Discovery = the “What”
• User Research
• Business Research
• Competitive Analysis
@lishubert Agile’s Secret Step: Discovery May 14, 2011
20. Product Roadmap
• The “What” prioritized
@lishubert Agile’s Secret Step: Discovery May 14, 2011
21. Same Page
Business
Technology/IT
User Experience
@lishubert Agile’s Secret Step: Discovery May 14, 2011
22. “Hey guys here is
what to build
next.”
Strategy
@lishubert Agile’s Secret Step: Discovery May 14, 2011
23. “Hey guys here is “Roger that. Oh
what to build and by the way...”
next.”
Strategy Project
Communication
@lishubert Agile’s Secret Step: Discovery May 14, 2011
24. Agile
Strategy Project
Communication
@lishubert Agile’s Secret Step: Discovery May 14, 2011
25. Agile
Strategy Project
UX Communication
UX
@lishubert Agile’s Secret Step: Discovery May 14, 2011
26. Product
Strategy Project x n
Communication
@lishubert Agile’s Secret Step: Discovery May 14, 2011
There are really 2 secret steps to Agile. Discovery and Planning. They go hand and hand.\n
When I say Agile I mean a project execution methodology that is in opposition to something like waterfall.\n
Waterfall we had a phase we knew where we “fit”\n
But where do we fit in in Agile??\n
\n
\n
I learned Agile in a large corporation.... nickname the Titanic\n
By decreasing risk to the code and releases the IT team on the “Titanic” promised to increase speed and efficiency\n
Nobody could say where UX fit into Agile\n
Currently it’s all about increasing speed and getting to market faster.\n
What everyone forgets is that agile was created as a development methodology.\n
but what are we building? What is the product? Who are the users? What is the context of use?\n
On the flip side, companies think that “agile” is their golden goose, promising them lower overhead and more speed. They still don’t know where we fit in or what we do.\n
Two main problems.\n1. UX/Design slows agile down. That is because we have no idea who are users are, what the context is for our designs and what content goes into things. Not having this background causes the “churn” discussions.\n2. IT release bugs/errors because they don’t have complete use cases. Thus spending the next several iterations fixing problems instead of extending the product.\n
We blame the methodology, but it’s not Agile’s fault we are implementing it incorrectly.\n
Let’s start by looking at what makes agile successful then add in the UX pieces.\n
Have a beer backlog and knowing the order that the backlog is being bottled allows this bottling assembly line to move fast. Think of agile like an assembly line. When we do that we realize we need to have a feature backlog that is prioritized.\n
Discovery gives us our feature backlog.\n
Planning with our biz and tech partners gets us the prioritized backlog.\n
The outcome of having this 2 things gets all of us on the same page as to what is being created, why, and in what order. \n
Skillset wise we end up with a strategy group that is constantly researching and prioritizing outside of agile. They are determining what features should be built next and queueing them up for the project teams.\n
At the same time the project teams are doing their own research and design on a specific set of features. They should be providing feedback to the strategy team and vice versa. This is NOT modified waterfall process, but instead these teams work in tandem. \n
The project is what Agile was created to speed up. By taking all the churn causing decisions and discussion out of the project we are able to increase speed. \n
These are the places where UX fits in. Keep in mind there are awesome design problems to solve within the project, but having a focused set of features gives us our design constraints to design within.\n
Thus our product consists of an overall strategy that is being built by 1 - many projects.\n
Remember Agile is like an assembly line. We need a prioritized backlog to keep the line moving.\n
Discovery gets us our back log\n
Planning with our Biz & Tech teams prioritizes this backlog\n
Thus we get increased speed by removing churn and focusing design and development. Decrease user risk by not developing features the user doesn’t want and decreased tech risk\n