Having an unhealthy culture creates a lot of unnecessary rigor and process for development and product teams. When upper management learns to truly trust everyone who works for them it unleashes an incredible amount of power and efficiency for teams and the company. Having worked in unhealthy, politically charged environments in the past and now working at Pluralsight, I can more clearly see how trust and a healthy culture saves the company a lot of time and and wasted effort. Below are some examples demonstrating this power.
So you think you’re agile? Perhaps so, perhaps even more agile than the teams I work with at Pluralsight. But let’s talk about that. When I first learned about Agile I thought of it like a boolean…either a team is agile or they’re not. I’ve since learned that agile seems to be a spectrum and I suspect our industry hasn’t yet fully discovered the most agile end of that spectrum. I’ve heard of teams that say they’re agile and what they really mean by that is just that they have a daily stand-up. I’ve heard of teams that say they’re agile because they strictly follow Scrum. Or that they’re agile because they’re using XP (eXtreme Programming). I’ve said this before and it’s not untrue. Done well, both are different types of agile, but, in my opinion, Scrum and XP are both pretty heavy methodologies. At Pluralsight we are trying to use Lean practices and it seems that we are constantly learning ways to do it better. I suspect there are teams in the world who do it better than us and perhaps with something different from Lean.
In addition to working in completely cowboy coding shops (no defined processes or controls), I’ve also worked with Waterfall, XP, and Lean. I’m so grateful for what I’ve learned from each of them. I haven’t actually worked in a Scrum shop, but I’ve studied a little about Scrum. If I were to rank them from heaviest (most time consuming and the most hoops to jump through), I’d say Waterfall is at the heavy end followed by XP and Scrum, then Lean and then Cowboy. Cowboy shops are fraught with peril and I’m not really going to talk much about that. Waterfall is very process heavy and a very slow process that typically delivers large chunks every 6-12 months. XP and Scrum have much less process and try to deliver every 2-4 weeks. Lean is even lighter and can ship new features daily or even multiple times a day. If this is all true, why ever use a heavier process? Well there are lots of reasons, most of them are related to the environment (management, product, politics and culture) that we work in. I’d like to talk about how culture and politics (and therefore management) may be causing you to use a heavier process than you need.
First lets consider something that is common in most agile methodologies: Iterations and sizing and planning meetings. When I worked for 1-800-Contacts, it was one of the best places I’d worked up to that point. The culture was pretty good and it was a pretty good XP shop. Our iterations lasted for 2 weeks. At the end of the iteration we’d deliver whatever we finished in that 2 week period. The beginning of each iteration started with a sizing meeting where subject matter experts would share with us the work that needed to be done and then we’d spend a fair amount of time sizing each story. Then we’d have a planning meeting with the team leads and some representatives from the business where we’d decide how many of the sized stories we could fit in the up-coming iteration and prioritization decisions would be made because there would always be more work than time (as is the case everywhere). This would be followed by another planning meeting with just the devs where we’d discuss the plan of attack for the upcoming iteration. There are a lot of details I’m skipping here, but this isn’t meant to be a discussion of how XP works. The point is we spent a fair amount of time sizing stories and figuring out what we’d do in the upcoming iteration. While this work was important for the success of our process, it wasn’t directly related to delivering value to our customers. The more time we spent in these meetings, the less time we spent developing features our customers would love. So why do it?
Well, in an XP environment with 2-week iterations, the business really wants to know what is going to be shipped in 2 weeks. It’s important to their prioritization process because if it doesn’t get in this iteration they won’t get it for another month. That puts a lot of pressure and a lot of questions arise like, “Really this is a 13-point story? How is that possible? It seems so simple!” So, why size things? Why not just ship whatever you can ship every 2 weeks? In my experience it comes down to trust.
Culture and Politics
For some reason, it seems really hard for other departments and upper management to just trust that the product/dev teams will work on what is most important and that they’ll stay focused and “work hard.” To some degree I think this is human nature, and to some degree it is a problem with western management philosophy. But it’s magnified when they, also, are not trusted. They know that if the hammer falls on them they need to be able to say, “I’ve been doing my best to push them to get it done.” But what if no one had to worry about the hammer falling? Ever. Not the dev team, not the dev managers, not the product team, the sales team, the marketing team…not anyone. This is what I’ve experienced at Pluralsight more than anywhere I’ve ever worked. It’s not perfect at Pluralsight because everyone is human, but I have been extended more trust here than anywhere and that seems true throughout the organization. And it is only possible because it starts at the very top. The CEO trusts everyone. We have rigorous hiring practices and we trust who we hire. That trust means we trust people not just to always be working, but to be motivated to do what is best for Pluralsight. When people aren’t worried about being reprimanded for failure there are a lot of processes that become unnecessary. I believe this is what has allowed us to develop and embrace lean processes.
We don’t have iterations, we deploy whenever we have something ready; sometimes a single team deploys to production multiple times in a day. Across all our teams we are definitely deploying to production several times on most days. We don’t have a QA team. We expect and trust the developers to not commit something that is not ready and once it’s committed we expect and trust them to test it in our staging environment before it goes to production.
Our product/dev teams are a cross-functional mix of product managers, designers and developers. On most teams we do still have a regular planning meeting, but it’s more of an opportunity for us to learn together what is most important and to make sure we’re working on the highest priority features. But we don’t size things, we don’t even make explicit commitments about what we’ll get done when. There are conversations occasionally about approximately how long we think something will take so we can prioritize better, but everyone understands that these are very rough estimates and typically they aren’t even discussed once we’re done with prioritization.
Once things are prioritized we just grab the next most important thing, work on it till it’s done and then grab the next thing…rinse and repeat. When it’s done, we deploy it to production. When a feature is done and ready for customers, we release it to them. No waiting for it to go through QA (we’ve already done that), no waiting for the scheduled iteration release date (there is none). It’s simple and it’s powered by trust.
There’s a lot more I could say about our process — perhaps I’ll write up another post that goes more in depth — but I think it’s healthy and important to think about why we do things that don’t directly deliver value. Think about what would happen if you eliminated it and keep asking why until you get to the bottom of it.
We still have more to learn, but I love what we’ve got going for us at Pluralsight. It’s such a healthy environment — no finger pointing, no political jockeying, and a lot less time wasted on things that don’t deliver value to our customers. And so much of it is powered by our culture. A culture of trust.