Three Key Principles to Operating as a LeanUX Team
Coaching teams here at PayPal on what it takes to operate like in a LeanUX manner. I have typically boiled it down to just 3 key principles.
Three Principles
1. Maintain a Shared Understanding at All Times
This was key when I was at Netflix and I see it even stronger now. A lack of a shared understanding means you will have have to lots of documentation. Having documentation that is predictive in an iterative environment is problematic. It is not realistic since you need to be able to change assumptions and solutions early in the cycle. Historical documentation becomes more necessary as teams downstream need them.A good way to alleviate much of the documentation normally needed is to pull the teams that are normally downstream (like QA, Localization QA, Localization, etc.) and bring them up further in the earlier cycles. Additionally you can create tools earlier in the process that proxy for these teams and reduce the number of those representatives you will need. Tools downstream should be automation driven as much as possible.
In a recent LeanUX project I kept referring to a/b testing. At some point it became apparent that not all the team understood what I meant by a/b testing (remember this is what I ate, drank & slept at Netflix). It was an easy solve to get us a shared understanding, but the mistake was assuming we had one already on all topics.
2. Collaborate, Collaborate, Collaborate
Walls between teams get erected whenever teams get big, become overly specialized and work in isolation. Agreeing to work as a team, trust each other and make collaboration the underpinning of the team's ethos will ensure the walls will come down.
It's not easy. We like to retreat back to the comfort of going solo or dictating to another the way things work. How can you tell where the walls are? It will be at those hand-off points that happen across disciplines. Collaboration is the opposite of this toss it over the wall mindset.
It's ok for teams to take time to work separately or have sessions to reflect. But if you are doing this to avoid working as a team then watch out. Trouble is already at your door.
3. Build/Test/Learn -- or Get to the Customer Early & Often
This is the secret to getting rid of team politics, getting rid of the prima donna, getting rid of analysis paralysis. Getting to the customer in usability tests, research, a/b testing and so on and doing it on a weekly or bi-weekly basis if at all possible keeps the team pure. It is the difference between a stagnant pond or a clear lake fed by streams. User data & user feedback will keep the team focused on the customer and the real goals of the product.
Believe me this really works. It is astonishing to see how much ownership takes over the team when they sit in all the usability sessions as a team and watch the successes and failures of their work. I have seen the full team time & again go out of a session that didn't go so well with a renewed determination to nail it next time. Customer feedback is the elixer to what ails you (now I just have to mention that all of the standard practices of how to gather this feedback and what to do with it still apply).
It's Pretty Simple
Fragile is often the name given to agile projects that are busted. I have used the term "Lean-Fall" to describe that ugly mix of waterfall & LeanUX. When I talk with teams that are struggling to work in an agile manner it could be a host of issues. There is a lot of machinery from an agile practice standpoint that might need tweaking.But frankly, over and over I have seen it come down to one or more violations of these three principles. If you don't have shared understanding, collaboration and continuous customer feedback, no amount of scrums, scrum of scrums, agile coaches, etc. is going to make a difference.
View what you are doing as a team in light of these principles and see if it doesn't give you a fresh perspective on acting like a startup.
If you like this article, you might want to check out my Anti-Patterns for LeanUX presentation.