Not all teams are able to function in a lean environment. Some companies have a lot of necessary risk they need to mitigate that generates a need for more process, documentation, and predictability. But for those who are able to cut out unnecessary process, there are a few skills that can be beneficial.
Be comfortable with change.
Since the idea of lean is to adjust based on learning, teams can only function leanly if they aren’t married to their ideas or dogmatic in their processes. This is why lean practitioners love simple tools like whiteboards and sticky notes — what they write or draw on them only takes a few moments to create, and that content is so easy to erase or throw away that it helps keep emotional distance from the idea. That way, they can determine honestly whether they’ve proven or disproved their hypothesis.
Google has popularized the concept of design sprints by utilizing some lean techniques. In a design sprint, participants use letter-sized paper to sketch out ideas and collaborate with one another with the goal of creating a simple paper prototype (though sometimes they use software) that they can then test with users by the end of the week. Teams using design sprints allow ideas to come from all over the organization and uncover answers about product direction. In the process, many ideas are discarded, and the user feedback drives the next sprint’s work.
Communicate well, and often.
Teams that cut out documentation and processes can only be effective if they fill the void by talking to one another, either virtually, in person, or both. It’s helpful to ensure everyone is using similar definitions for words, especially jargon or acronyms, to ensure that there’s a common understanding of how the team is using those words.
Collaborators also need to talk about the things that are and aren’t working for them. To mitigate waste in the work the team is doing, the processes used will constantly need to be evaluated. The most efficient way to do that (without adding more processes) is to do quick check-ins for understanding. This cultivates an environment where colleagues are comfortable speaking up when something isn’t working.
Talk to users.
The only way the build-measure-learn feedback loop works is to put something in front of users and talk to them about what’s working and what’s not. Some might say that quantitative data is sufficient in measuring success, but that view is quite short-sighted, especially when it comes to developing new products. Quantitative data tells you there is a problem, while qualitative data tells you what that problem is and why it exists. It’s only then that teams are able to know how they should iterate on their product.