Over the past decade, innovative companies, software industry thought leaders and lean/agile pioneers have discovered simpler, sturdier, and more streamlined ways to be agile. While there is timeless wisdom in agile, today’s practitioners would do well to bypass outmoded agile practices in favor of modern approaches.
Modern agile methods are defined by four guiding principles
* Make people awesome
* Make safety a prerequisite
* Experience & learn rapidly
* Deliver value continuously
World famous organizations like Google, Amazon, Air BnB, Etsy and others are living proof of the powers of these four principles. However, you don’t need to be a name brand company to leverage modern agile wisdom.
In this talk, Josh Kerievsky will explain what he means by modern agility, share real-world modern agile stories, show how modern agile addresses key risks while targeting results over rituals, and reveal how the 2001 agile manifesto can be updated to reflect modern agile’s four guiding principles.
Video Transcript
Brian Button: And now, your keynote speaker, Joshua Kerievsky.
Joshua: Thank you. Thank you. I thought I’d balance out some of the Rolling Stones with a little Frank Sinatra. Welcome, everybody. I’m really truly excited to be here. I lived in Georgia once, back in the 80s, so I can say, “How you all doing?” It’s just an honor to be here. I’ve been involved in this movement for a really long time, back to the 90s, as Bryan just said. I haven’t been at this conference in about five years. It’s a pleasure to be back here. My god, it’s really grown. It’s incredible, so awesome.
I want to thank Bryan Button for inviting me here. I want to thank Jessica Small for the incredible coordination. I really want to thank the sponsors of this conference and the Agile Alliance. I really also want to thank the volunteers who generously put out about 2,500 Modern Agile stickers on all your seats last night. Thank you.
I’ve got a lot to talk about. Hopefully, there is time for Q&A at the end because I’d love to talk to you. Let’s get started here. Also, for the Snapchatters, there is a modern Agile geo filter just today. I’m excited about that. All right, I am not going to talk about scaling today. I’m also not going to talk about scalification. I am not going to talk about enterprise scalability frameworks. In addition, this is not a political speech. I am going to talk about this. Right? This is supposed to be modern. I am also going to talk about this. Finally, I’ll be talking about this.
Now, you’re probably very intrigued and that’s what I want. Let’s keep going. Obviously, our topic today is Modern Agile. What is this? What is this thing? First of all, it’s completely open source. There is a ModernAgile.Org website, even the graphics are open source, the font is open source. It’s really something for the community.
These four practices or four values that we talk about in Modern Agile, they are basically make people awesome. I think the thing that’s been missing from Agile has been direction. What direction are we going in? We could be really Agile, but if we’re going in the wrong direction, we’re not really solving major problems. We need to focus on making people awesome. Not just our users, but our coworkers, our stakeholders, our managers, everyone in our ecosystem. Make people awesome.
Make safety a prerequisite, if you really study Lean and if you studyextreme programming and you look at some of these things that we do to make safety present, you can see how important this is. We’ll talk later about an important Google study that looks at psychological safety. Safety is extraordinarily important to high performance. Then we have experiment and learn rapidly, right. This borrows a lot from Lean Startup and from lots and lots of smart engineering that values learning and rapid feedback loops. Finally, deliver value continuously. These four, I call them principles, you can call them values. You can call them thingies. They are the four things that I focus on.
Let’s take it for a test drive. This is a photo from my car. I can’t live without this thing anymore. People have this in their cars? These things are incredible because the heads-up display, when I’m trying to park, makes it so much easier. It’s always on. It’s always showing me these colors as I’m trying to park, parallel park. It looks like this, the heads-up display is always on so it’s always delivering value to me.
The experiments I can do to try to fit into parking spots that I should not be able to fit into are pretty cool. I feel safe because I’m not going to bump into something or someone. It just makes me awesome at parking. Modern Agile, not just for software development. I think we’ve grown past that, right. There are sessions here this week on Agile in HR and Agile in marketing. We see Agile moving way beyond just software development, where it was when I first started out.
First off, who am I? I’m the CEO, Founder of Industrial Logic. I started this company in 1996. We help companies get better at software development. Like Bryan said, I’d been around a long time. I couldn’t find pictures actually for this presentation. I had to go back to the way-back machine to find some old photos. Here is one from 1999 where I was pair programming, you could see the old monitors there. I’ve done a whole lot of Agile coaching in my time.
I wrote a book called, “Refactoring to Patterns.” I’m overdue for a new book, so maybe you can bug me about that. I created something years ago called, “Industrial XP” which helped spread extreme programming to companies across the organization. You see, I didn’t use the word “Scale”. I’ve written a lot and created a lot of multimedia e-learning to help more and more people around the world learn important practices. Finally, a few years ago, I created something called Anzeneering, strange name. It’s derived from a Japanese word “Anzen” which means safety, and it’s really inside of Modern Agile today.
Okay. Now, I’m going to take you back for a minute to 2008. The Agile conference. I believe this was from the breaking act stage or I forget what they called it at the time. It was the stage where you introduce new ideas. At the time, we had been doing fixed length Sprints or iterations using story points, doing those things for many years. We finally started breaking with that approach. What happened was we started to see that we could do little bits of work and ship it, little bits of work and ship it.
We didn’t need these time boxes anymore. They were getting in our way. This session I talked about back then was about what I called at the time, “Micro releases,” little releases. We no longer had fixed length time boxes. They were variable length like you see with those lines. They were on the order of half a day to three or four days. That’s really what we did. This was the beginning of us not really estimating anymore, just picking stuff that was small and valuable, shipping it, right. We didn’t have a hashtag or Twitter back then so we didn’t really call it no estimates, but that’s really what we were doing.
That change happened for us and it was liberating, really liberating. Of course, we didn’t see a lot of other people doing that at the time, but something really funny happened. I went to a customer in the Silicon Valley. We had been helping this customer, one team, initially transition to an Agile process, little managerial stuff, little technical stuff. The company liked what we did. They said, “You know what? We want to spread this across the whole company.”
I said, “That’s great but I’d like to go talk to the first team that went through the transition and just hear what their experience was so we can customize it for the rest. I met with this wonderful project manager. She is one of the best project managers in the whole company. I walk in the room and she has got all these posters on the walls, right. Sprint, burned down charts and all kinds of release plans and all of the kinds of things that you’d expect in a traditional Agile shop.
I looked at them. I asked her how things were going. She said, “It’s all going really great.” There were something about the way she was talking where there was something missing. There was something there. I just probed a little further. I’m like, “Is this really working for you?” She is like, “You want the truth?” I said, “Yeah. I want the truth.” She said, “We don’t do any of this stuff. See these posters up here? We made them because you were coming.”
I was like, “Well, what do you do?” She is like, “Well, we gather together. We choose some work to do. We gut estimate what we think we can do and then we do it. Usually, it’s about right. Sometimes it’s a little off but it’s no big deal and that’s what we do.” I was like, “Well, that’s fine. That’s what we do.” That was funny, that experience. Now, many years have passed since then and I go around and I see a lot of old stuff. I made this analogy in my blog where I said, “It’s like seeing someone with a really big fat heavy laptop and you just feel bad for them.”
When I see people doing old Agile processes, that’s how I feel. It’s like, “Wow. You’re way behind.” I don’t mean to beat up on this thing here, but it’s a little old. Okay? It’s had a wonderful lifespan. It is a distinguished part of our history. It deserves an honorable retirement. The food is great there and they have activities. I think there is Battlelog Bingo on Thursday nights.
Tell me if this happens to you. You start a Sprint. You’re feeling pretty optimistic. Then you’re not so sure if you’re going to get everything done. Midway through, it’s not looking too good. Then it’s just starting to get worse. Then by the very end, maybe you’re doing bad things just to get done. Maybe you’re no longer testing or refactoring. I meet a lot of people that say that to me. They confess, “Yeah. We get the stories done but we just drop all this other stuff to get them done,” or they don’t make it at all.
If they don’t make it, we typically see the story going from one Sprint to the next. It’s not that different from what Waterfall was. It’s just in a little outfit called Agile but it’s really Waterfall. Now, teams can beat themselves up and say, “Well, it’s one day we’ll have a perfect velocity. We’ll meet our velocity estimates,” Nonsense, total nonsense. I used to believe that stuff.
All right. What else can we say here? These guys, two people I respect quite a bit. They both signed the Agile Manifesto back in 2001. They agree, “Velocity is killing agility.” Ron Jeffries is apologizing for creating story points. Isn’t that interesting? Jeff Gothelf wrote a book called, “Lean UX.” He says, “We got to get out of the deliverables business.” Now, so many places that are adopting Agile are interested in, “How many stories did we get out? What’s our story capacity?”
A lot of Lean UX people and Lean people are saying, “Wait a minute. What outcomes are we going for? What are we trying to achieve for the business, for our users?” Not, “How many stories did we produce?” The definition of done in traditional Agile has been pointed out to be really broken especially by people that are advocates of Lean Startup. They say, “Wait a minute. If you’re inside the building and you’re looking at what’s done and you think you know what’s done, you don’t because the users have to tell you what’s done.”
The users have to say, “Yeah. We’re using your feature and it works for us or it doesn’t work us. They determine what’s done, not the product owner, very old-fashioned concept of a product owner accepting things to mean done. Definition of Agile? This is not Agile. Doing these rituals does not make you Agile. Now, this is where people, you might be thinking, “You know what? I disagree with this guy. Who is this guy? I disagree with him. This is the starting point for Agile.”
This is the training wheels, right. People have told me this, “Josh, you’ve been doing this a long time. You’re advanced.” Now, I say that I’m advanced. Does that mean that if I have a new computer user, I should give them a big fat laptop because they’re not advanced? No. I’m sorry. Things get streamlined. They get safer. They get sturdier over time.
Let’s talk about training wheels. This metaphor has been around a long time. Here is a dad at our local playground, very concerned about his daughter learning. She has got the training wheels there. Unfortunately, she wasn’t making much progress. He had all his tools as well. He was adjusting the height of those training wheels. A little more of him and her. This is when he took the training wheels off and he is just really holding her closely to make sure she doesn’t fall.
Now, I want to talk about pushbikes. The pushbike is a very old thing but it’s become really popular for teaching kids how to ride their bikes. There are no pedals. The pushbike is all about balance. Now, we had an old bike. It wasn’t a pushbike. You know what? My daughter was learning to ride. I said, “Why don’t you try not pedaling and just learning to balance?” I want to show you a quick video of how that went for her.
Video: Oops. All right. You’re okay. There is an old expression, “When you fall off a bike, get back up on it.” Ready?
Joshua: Thank you. That was an incredible thing, 24 hours that happened. She was riding her bike and it just feels absolutely remarkable. I bring it to you today because I want you to be maybe inspired by the idea that things can change in the way we learn how to do things, like maybe Agile.
This concept of starting with Sprints and stand-ups and story points might be the training wheels of Agile. I want to explore some newer ideas. Let’s do that. Now, a lot of these ideas, you might say, “Josh, what’s modern about them because we heard about them five years ago or we heard about them 30 years ago?” Wisdom never goes out of fashion, right. I think practices can get antiquated, real wisdom doesn’t. There are some new things you’ll see here. Maybe there are some old things you’ll see that I still might call modern. The future arrived for a lot of people a long time ago, it’s just not evenly distributed. Not everyone learned about it yet.
Time for new beginnings for me happened this past, actually the summer of 2015 into the early fall. This little puppy showed up. Now, really, we have two cats and a dog already. It’s like I don’t have any time or energy, space for a puppy. I reluctantly took on this puppy as a foster. What happened was at the time, I realized he had my legs. I was like, “You know, maybe we’ll keep this guy.” That joke didn’t work. I’ll write that down for next time. At the same time when we got this little puppy, I was starting to go to some spaces. Your Open Jam is like the open spaces of conferences that we have. This was in Northern California.
Actually the first one I went to was Prague. I was in Prague. Did an open space, a bunch of people showed up on this topic of Modern Agile. We scrolled some things on the board. There was a lot of interest. It was interesting. I learned something that day. They were very interested in these ideas. Modern Agile seemed to be something that I needed to talk about more. That’s what I learned at the open space conferences.
Gradually, it got to be a little more mature. I wrote a blog about it. The puppy started getting a little bit bigger and older, still making messes; and s till, Modern Agile was a bit of a mess too. I didn’t really quite understand what it was. This diagram that you see here, I no longer use it. It’s really not accurate anymore.
Then as he got to be known, Marley, Marley and Max became close brothers. Modern Agile matured a little bit. An actual graphic designer who works for us made that beautiful icon there. We started to see that, “You know what? Modern Agile really isn’t any practices. We’re not going to anoint in-practices and say, ‘Here are the 12 practices of Modern Agile.'” No. It’s just some values, just some principles. Four principles to be exact, that’s all. That’s all that is.
Here is a quick quiz for you. If you want something to stick, what do you create? A new process? A new framework? Or a sticker? That worked a little better than the other jokes, so I might keep that one. Okay. Modern Agile comes from a lot of wise people, a lot of smart people that have written some incredible books, given some amazing talks, leaders of our field. Kathy Sierra, many of you may have heard of her. She wrote an incredible book called “Badass, Making Users Awesome,” where she made it really clear, don’t develop an awesome product. Don’t develop an awesome company. Develop awesome users. Make your users awesome.
Other books like Managing For Happiness from Jurgen, we heard from him. Delivering Happiness from Tony Shay, the Founder and CEO of Zappos, right, books that really focus on the happiness of customers, the happiness of employees. Making people awesome, these books influence that. Then we have this movement into flow-based approaches, Con Bon, Continuous Delivery, Continuous Deployment. This concept that … And it’s from Lean so it’s very old, small batches of word delivered constantly. Get that value into production as fast as you can, especially if it’s helped you make people awesome.
The Lean Startup, if you haven’t read that book and you are in the software field, please go read it. It’s an absolute revolution in our field. You must read it. You must study it actually. Don’t even just read it. Study it. It is an incredible book. These other books are also incredible, the Startup Owner’s Manual, Steve Blank, changed the game. We know about product management. He talked about customer management, customer development, developing the customer, an entire process for that, learning really what the customer wants.
Experimenting and learning in Lean UX and other critical concept in Agile retrospectives, constantly learning from retrospectives. Finally, there is a ton of books in the safety field, extremely important stuff. I love this book called, “Driving Fear Out of the Workplace.” It’s an old book, but it’s incredible. The Power of Habit, best-selling New York Times Book, Charles Duhigg, Pulitzer Prize Winning Author. He has a chapter in there about Paul O’neal and what he did to change a way 100-year old culture using safety to take Alcoa to soaring new heights for their stock price and the happiest employees ever.
Amazing books have influenced modern Agile. Toyota Production System has also influenced it. There are wonderful two pillars of the Toyota way, respect for people and continuous improvement. These things are in modern Agile. Where are they? Well, respect for people, right down the vertical axis. To make people awesome and to make safety a prerequisite for people, you’re respecting them. You’re respecting their time, their money, their health, their information.
Continuous improvement, right, experiment and learn rapidly, and deliver value continuously. This is how we continuously improve. We may not know how to continuously improve so we experiment and learn. Once we do, we need to deliver it to really improve. The two pillars of the Toyota way, right there inside of Modern Agile.
I believe that agility requires balance. When you first start learning Agile, just like the pushbike, you need to learn to balance first. You don’t need to learn pedal real quick. Learn to balance. My brother got an incredible ride on these dolphins. I’m very jealous. I think of the two dolphins of agility, often called this Double-Dolphin Agility. One dolphin could be respect for people. The other dolphin is continuous improvement.
The Agile Manifesto, incredible document, historic document, wonderful thing and old now. It was focused just on software. We can update it. I didn’t set out to update it when I started exploring Modern Agile. The more I explored it, the more I looked back and said, “Maybe this is saying things in a more modern way, in a more accurate way. We are no longer just trying to develop software by doing it and helping others do it. We’re doing all sorts of things with Agile. We’re focused on outcomes. We are uncovering better ways of getting awesome results. That’s what we’re focused on.
Let’s dive deeper into some of these practices. Make people awesome, okay. I’m going to take you back to Japan in 1955. This is post-World War II. Japan is an absolute mess. The train systems in Japan are extremely slow. If you want to become … If you want to rebuild your economy, you need to move people and materials rapidly across your country. The head of the Japanese railway system was asked to make faster trains. He asked his engineers in turn, “I want you to make a train that goes really fast.”
The engineers basically said, “Okay. Well, we can make something go 55 miles per hour.” He said, “No. No. That’s not fast enough.” They went back to the drawing boards, they tried some things. They said, “We think we can get one going 75 miles per hour.” The head of the Japanese railway system said, “That’s not fast enough. I want it to go 120 miles per hour.” This is 1955, 1956. They say, “That’s impossible. If it’s go around a turn, the centripetal force would just take that train right off the rails.” He said, “Why is there a turn? Make it straight.”
He said, “I don’t have every answer, but figure it out. I know you don’t know how to figure it out right now, but figure it out.” 1964, the Tokaido Shinkansen leaves Tokyo and is traveling at 120 miles per hour. Jack Welch, the CEO of General Electric at the time, came to Japan in the early 90s, heard the story of the Japanese Bullet Trains and was blown away.
He said, “Wow. We need Bullet Train thinking at General Electric.” He came back to General Electric. For every division, he said, “What’s your Bullet Train thinking?” Bullet Train thinking means you don’t know how you’re going to get there. It’s some awesome thing that you’re trying to do, make people awesome. Have a direction.
Now, I’m a dad. My daughter turned … This is Eva again on the right there. She was turning 8. She asked me to have a water balloon fight. Now, how many of you here have ever made a bunch of water balloons for a bunch of girls or boys, whatever? It’s a lot of work, right?
Male: Yes.
Joshua: It’s a lot of work. I was like, “Okay. We’ll have the balloon fight. Yes. We’re going to do that.” But I was dreading it. Until I found this.
Video: Water balloon, water balloon technology.
This is some cool trick, trick.
Take more.
Joshua: All right, one of them popped. There was some water leaking out. I couldn’t get that to stop leaking out there. Overall, I made about 150 water balloons in a couple of minutes. It was painless. It’s wonderful. Someone thought to make me awesome at making water balloons. How fantastic, the girls had a ball. Making people awesome.
We need to think about the ecosystem, the entire ecosystem, right, of people that need to be awesome. It’s not just your users. It’s not just your coworkers. It’s a whole bunch of different people, right. We’ve sold some Agile e-learning. Over time, we’ve learned, “Wow. There is different kinds of people.” There are evaluators. There are salespeople. There are managers who buy this stuff. They need to be awesome. Lots of different people need to be awesome. Focus on them.
Intuit, incredible company, well-known for all kinds of programs. They’re well-known for having their engineers observe people using their software. They’ll go and observe them using Quicken or using Turbo Tax. These are real engineers who program going and observing the customers. They learn a tremendous amount and they come back with new ideas. They have the love metrics set into it. They say, “Let’s observe did we deliver customer benefit. Let’s find out from out customers. Are we delivering benefit?”
“Are they actively using it, our product? Are customers telling others about it?” They’re constantly looking at these metrics. Notice, they’re not really internal metrics. “How many stories did I get done? What’s my velocity?” They don’t care about that. They care about the outcomes in the world.
Make safety a prerequisite. This was part of a blog I wrote. A lot of people like to this retweet this so I brought it in. If you have this culture of fear, whether it’s you’re afraid to change the code because there are no automated tests. There is no safety net. Or you’re afraid of speaking up to your boss. If you have a culture of fear, none of this fancy stuff is going to help much. We have to attack that problem. One way we do it of course on the technical side is we have lots of automation. For our Agile e-learning, we have hundreds, thousands actually, thousands of automated tests of different kinds.
It’s an incredible safety net. When they were building the Golden Gate Bridge, they had a safety net. 19 people fell into it. They’re called the Halfway to Hell Club. Actually they studied this, and the cost of making that net was incredible. It was really inexpensive when they looked at the productivity of the workers because morale was so high when they had the net. They know, “I’m not going to die up here.” When they built the Bay Bridge, a bunch of people died.
Anyone use Slack? Very popular software, right? I love Slack for one reason. Well, for many reasons. One of them is they send me e-mails saying, “We’ve refunded you a certain amount because there was an inactive user or several inactive users.” Inactive users? They are refunding me? How many subscription services do that? They have my back. They’re protecting my money. I feel really good about that.
How many of you here use Apple Music? Not anymore. A few hands back there. Boy. What a problem. What’s on their backlog? Here is another one of my daughters. They’re all beautiful by the way, so thank you very much. She wanted the Beyonce album the day after it came out. Well, minutes after it came out really. They were charging 20 bucks for it on Apple but she had to have it because you’re going to school and you have to have it. You’re a teenager.
She got it. She thought she had it. She played some songs from it. She was happy and then it disappeared. Then she said this. Lots of other people said stuff. Tim O’Reilly was tweeting. Someone wrote a blog about How Apple Stole My Music. Tim O’Reilly has a lot of followers on Twitter. Then Martin Fowler has a lot of followers on Twitter. He retweeted Tim O’Reilly’s tweet. This is not good for Apple.
I wonder what features are they working on that are super cool versus are they making people safe? Is safety a prerequisite for their service. Really important. Google did a two-year study called Project Aristotle. They wanted to know what’s present on high performance teams. They studied and studied and studied. They got nowhere. They couldn’t find a common denominator until they finally encountered the work of Amy Edmondson. Amy Edmondson, Harvard Business Professor, wrote a book called “Teaming” and talked about psychological safety. They finally found their common denominator at Google. It was psychological safety. It was the number one thing.
Five things they found, it was the number one attribute of high performance teams, psychological safety. Team members feel safe to take risks, to be vulnerable in front of each other. Doesn’t matter if you play together after work or if you all are in the same location or if you have the right mix of people like the experts and the non-ex. That doesn’t matter. Is there a psychological safety present? That’s what determined high performance.
People change. Here is a director, chief of Google Analytics. He said, “Wow. After we learned this, I changed the way I ran meetings. I changed how I listened and whether I interrupted, and encouraged people to speak.” We boiled it down to five psychologically safe meaning tips, so these, you could take home with you.
Encourage everyone to contribute. There are plenty of times, even in my company we’re talking on Google Hangout because we’re very distributed. A few people won’t speak. Well, now we encourage them to speak. Listen to one another. How do you know that you’re listening to one another? Review and repeat other people’s points. Avoid dominating or interrupting. That’s pretty basic but you still need to be reminded to do it.
Be caring, curious and nonjudgmental, maybe when someone says something that might annoy you, be curious and nonjudgmental. This leads to psychological safety, very important if you want high performance. Now at Industrial Logical, we’ve been studying other fields to learn how we can improve. I went to a safety culture workshop. I was the only software person there. They’re like, “What are you doing here?”
All these people had these things called “Stop Work Authority” cards. They had the ability to stop work if it was deemed unsafe. It’s like Toyota’s Andon Cord on the production line. They had these cards that they carried around with them. I was like, “Well, why don’t we have this in the software field?” We made some cards.
They’re these little cards. I carry them around in my wallet now. I brought a few with me today. If you want some, come on up to the stage afterwards. They’re little cards that allow you to stop people. We also use it in Slack. We have a digital version of this too. It’s been very helpful in establishing safety in our company.
We also do something called Tailboarding. Tailboarding is where before we begin work on something, we want to analyze the hazards, the potential hazards for that work. Other industries do this. I met with a bunch of people from Austin Electric. They deal with the power lines and power grids in Austin, Texas. They do tailboarding. They gather together at a work site. Before they start work, they think about, “What are the possible hazards that we could run into? How are we going to mitigate those risks?” Before they do work. “This has helped us get better.”
Now, you got to be careful of defenses. Back in the 1500s, the French and English fought a battle, the Battle of Agincourt. This is when the French armor had reached its zenith in weight. It was so heavy that if they fell off their horse, they couldn’t get back up. The English easily defeated them because they were much more lightly clad and more agile actually. Defenses can harm you. I don’t want you think all defenses are good. Your own defenses can harm you. You got to be careful in what kind of defenses you make to make people safe.
Experiment and learn rapidly. Anyone hear of Paul MacCready? Paul MacCready is considered the best or one of the best engineers of the 20th century. He is famous for finally creating human-powered flight. Okay. He did it, a bunch of other people tried to win this prize. It was a prize for 50,000 pounds at the time, about $1.2 million in today’s money. That’s a lot of money. It’s like the X Prize today. Everyone tried to have human-powered flight. For 10 years, no one got anywhere. Paul MacCready came along and said, “The problem is we don’t know what the problem is.”
What he did was he created an airplane that he could iterate on within hours, not months. He’d make an airplane out of mylar and aluminum and other materials. Within a couple of hours, it would have crashed. He would have experimented there and learned. Then he’d have another plane. Then one day, he’d have four planes created. They learn so rapidly that within six months, they won the prize. They flew the appropriate distance and won the prize. Then a little while later, they flew across the English Channel and won the next big prize, all because of this very fast feedback loop, experimenting and learning rapidly.
Harvard Business Review did a whole magazine on this topic of learning from failure, “Rigorously extract value from failure,” love that phrase. IMVU, this is a company that Eric Reese founded, so if you read the Lean Startup Book, you’ll learn a lot about this. IMVU, it’s like the Sims but it’s a little different. It’s a 3D space where people meet. In the early days of the product, they had a product up, people were using it. It was an MVP, Minimum Viable Product. It was very minimum.
You could chat with other people, you could dress up and do things. You couldn’t move your avatar. People said, “We want to be able to move our avatar.” They started looking into it. It was going to take two to three months to build something like the Sims where you can move through 3D space with your avatar. That was going to take too long. Basically, they said, “Well, why don’t we just let you click somewhere and it just will teleport you? We’ll try that out. It’s only going to take two days to program it.
They did. They did it in two days. They did continuous deployment at IMVU and they put it out there. It looked like this. You just click, and clicking takes you to a seat or anywhere you want to go, just clicking, this is the teleportation. Very primitive, you might say, but the customers loved it. They said, “Wow. It’s even more advanced than the Sims.” They were astounded to get that feedback. They’d say, “What are the top three things you love about IMVU?” They said, “Teleportation.” Two days instead of months, right?
We talk about predictability. I need predictability. We don’t talk about taking something big and turning it into something tiny that adds a lot of value, right. That’s way more important. Maximize the amount of work not done. That’s in the Agile Manifesto.
All right. I got to go a little faster. To analyze this, they experimented with this feature. It could have been a disaster, but they did an experiment, a cheap, fast experiment. They deployed it, right. They basically discovered that people loved it, made people awesome. They loved being able to move around the space really easily. Ultimately, they saved their budget. They didn’t have a big budget at that time so they were very fiscally responsible, saving money by not building the Sims like movement feature.
All right, deliver value continuously, doing the impossible 50 times a day. This was a speech given by someone else at IMVU. These are the first people I knew of to do real continuous deployment, deploying 50 times a day with millions of users, incredible, unbelievable story. This is continuous deployment. We make it safe to deploy. Now, at another company down the road in Silicon Valley, here is what life was like.
Monday, “Hi. Checked in my code.” He is telling the product manager about the code checking. Product manager is saying, “Cool. Let’s get the other 69 to check in by Wednesday and we’ll be good to a build.” Wednesday, “Oh, not everyone checked it.” Thursday, “Okay. All code checked in. We should be ready to do a build.” “Ramon, please kick off a build?” Ramon, “Sure. I’ll have it right away. Uh, the build is broke.” It’s Friday afternoon. What do you think is going to happen? Developers are going to work all weekend. They’re not going to be too happy about it.
Monday is going to come and the QA person is going to say, “Wow. A lot of bugs in there, a lot of bugs.” Then the developers are going to attempt to fix all the bugs. It’s just going to continue and continue. This was happening. It was happening at a search engine company, not the famous one, the other one. This guy, my friend, Stas talked about this. He was allowed to talk about this publicly because an incredible story happened there.
Here is Stas. Stas basically said, with some other people there at the company, leadership said, “We’re getting rid of quality assurance. If you’re a QA person, you can either leave the company or you can become a quality engineer.” A quality engineer helps write automated tests and is part of the team building these automated tests constantly. They’re not a downstream entity. They took a lot of our testing and our factoring classes to help learn these skills.
From QA to QE. Then once they had lots of tests in place, they realized that Sprints were no longer really necessary because the way they used to do things, Sprints were almost little mini Waterfalls, or often called Scrumer Falls. Once they had many automated tests, they could do more continuous flow. The problem was they still had manual builds. They automated that too to be continuous deployment. Now, it took about two to three years to do this. Now, every shipping product at Yahoo does continuous deployment. It’s an incredible story.
All right, some really quick case studies for you. This is Osteria Francescana Massimo Bottura. He, to me, is one of the geniuses of our time. I want to show you what he did. First of all, he is a total artist. He runs a three-star Michelin restaurant in Northern Italy. This is one of his dishes, called Camouflage. This is the Five Ages of Parmigiano Reggiano.
This is his sous-chef, Taka. One day, they had … It was almost closing time. They were supposed to serve two lemon tart dishes to a group. Taka dropped one of the lemon tarts. It fell on the side of the plate, on the counter, and it broke. Taka was really distraught. Here is what happened.
Video: I said, “Taka, stop, stop. Look through my fingers. That is beautiful. Let’s rebuild as it’s broken stuff.” Immediately, he didn’t understand but he trusts me so much. He said, “Okay. Let’s try.” We get the lemon zabaglione, and we spread it on the plate. We just like this, like … Then we rebuilt on the other plate, with all the single precision to make them feel we did that for purpose. That was the moment in which we create, “Oops. I dropped the lemon tart.”
Joshua: Absolute genius. I mean, “What’s it like to work for him?” Here we are. Let’s do an experiment. We just broke a lemon tart, let’s experiment with a new dish. We don’t want to make our customers wait so let’s deliver it to them right away. How awesome is it now that it’s an iconic dish of the restaurant, they made this … This per … It’s an iconic dish of that restaurant. That sous-chef made an incredible dish by making an accident, making a mistake. It is an incredibly safe restaurant.
Hello? Maybe I’m out of time.
Male: It’s the lemon tart.
Joshua: It’s the lemon tart, yes. This is a wonderful opportunity here. How incredible is it to work for Massimo where it’s safe to fail? Because everyone is going to basically do this thing again and turn the … Into an incredible dish. I want to talk about Myles Recny, a 22-year old guy, worked at a social gaming company.
Miles was working at a social gaming company that wasn’t too sophisticated with software development, unfortunately. He was building … Asked to build a new feature. He is a liberal arts major, like myself actually. He was basically writing software that was hitting the production database in development, developing software but hitting the production database using a new table. It was a new table, nothing was really being affected.
Until one day, he accidentally deleted the user table. That’s not something you really want to do. All hell broke loose. It was bad. It turned out they didn’t have backups. You’re talking very primitive software engineering culture there. Poor Myles. Didn’t realize he was in such a culture. The CEO brought him into the room because all hell is breaking loose. They’re having to recreate the database tables by calling customers saying, “What did you buy? Let’s input it.” Bad. The CEO basically called him into the room and said this. He is not Massimo.
Now, in the safety literature, people like Todd Conklin will say things like, “Never place a worker only one defense away from failure.” Right, this guy was very close to failure. He was right up against it. He didn’t have any protection. No one was making him safe. We barely even have to spin this wheel because none of this stuff actually applies. I mean, it’s all bad, right. I’ll just skip through it because they’re not doing that.
What about this company? Etsy. They had a site outage. They had an engineer seventh day on the job, seventh day on the job. He deleted a CSS file, continuously deployed it. It brought down Etsy. Huh. Normally, this is what happens. Not at Etsy. Seth Godin remarked, “People are not afraid of failure. They’re afraid of blame.” In a blame culture, you’re going to have problems. It’s not the way at Etsy. Etsy is a blameless culture. Etsy has studied the literature and looked into how to create a culture where it’s okay to fail, where we can learn from it.
This guy got the three-arm sweater award. It’s an award they give out once a year to the biggest goof-up that helps them learn so much. They learned. They said, “Shame on us for creating an architecture that can bring the site down because one file is missing. Shame on us. Thank you for revealing this to us.” He continuously deployed. He thought he was doing it safely but apparently not. They immediately did a retrospective, they do blameless retrospectives. It’s very clear. Every retrospective is blameless at Etsy to learn. They did learn. They learned how to improve the designs so it wouldn’t be so fragile. It’s really safe to fail there. How awesome is it to work at Etsy when that’s the culture, right?
I want to talk about Hunter. There are some several people here from Hunter Industries in Southern California. They make irrigation systems. One of the things you could say about that employee at Etsy was that he probably was working alone. They don’t do that at Hunter. Hunter does mob programming. A bunch of people get together and program together all day long. It really simplifies a lot of things.
Remember I kept showing you that old diagram of process and how we used to do things in the 90s and early 2000s? They don’t do things like that anymore at Hunter, not at all. Lots of practices have dropped away because things are much simpler, more streamlined in this mob programming process. They have high quality. Let’s study it from the wheel here. Make people awesome.
If you’re new to programming and you’d come into Hunter, boy, do you get good really fast because you’re programming with a group of great people. Everyone is taking turns at the keyboard every fifteen minutes. It’s an incredible learning opportunity. You become awesome. Experiments are encouraged so you can learn rapidly. Even the developers are encouraged everyday to take an hour to try out some new tools, to build some new tools. It’s not a product owner saying, “Here is exactly what to build.” “Hey, developers. See what you could build to add value to the company.”
Several tools they built have become very very important to that company. Experiment and learn rapidly. They build little prototypes and show them, see if they need to grow into full products. Safety, it’s incredibly safe to do mob programming, unbelievably safe. You got all these eyes and minds participating with you, hard to make mistakes like the guy at Etsy or Miles. They also practice forms of continuous deployment there, continuous integration, continuous deployment.
Okay. Airbnb, another example. They have a phenomenal program around continuous deployment. If you’re a new employee entering Airbnb, you will deploy code to production within your first two days. You will be given your own new development environment. You’ll have a mentor. You’ll be given either a bug to fix or a tiny new little feature to add. You will deploy it to production.
They value continuous deployment that much that it’s part of their onboarding program. Everyone goes through this. They even have special tooling that when you do a deployment, you can see if business metrics are changing. They have an entire dashboard that shows you the business metrics to see if your change either negatively or positively affected business metrics, incredible.
I want to skip that and just move this on to go a little faster. I’m going to skip this guy. Unfortunately, he is … It’s a sad story, but his company basically doesn’t do continuous deployment. They do manual builds. He left the company. They don’t recognize him. They never give him any kind of recognition. I’m not going to bore you with that.
I want to get to this guy here, Jeff Bezos. How many here use the Fire Phone from Amazon? No? Nobody use that? Oh. Yeah. Big flop. Big flop. Jeff, what happened? Reporter asked him, “What happened?” You know what he said? This. We are looking at these things as a venture capital fund. There’s all these different projects. We expect to fail. In fact, we’re proud of being a great place to fail.
Amazon, fastest company to reach $100 billion in annual sales. Hit $10 billion for their AWS, faster than even Amazon in annual sales. Jeff observed that they have this organizational culture that cared deeply about an act with conviction on four principles. Okay? This is very similar to Modern Agile, so I found it interesting. What are they? Customer obsession. Eagerness to invent and pioneer, willingness to fail. They’re very willing to fail. Taking professional pride in operational excellence. They deploy to production every 12 seconds. Finally, patience to think long-term. They have a very long-term perspective, very unusual for any company on the stock market.
Now, there have been talk of Amazon not being that great to some of their employees sometimes. I read some of those articles. You don’t see that reflected in their organizational culture, so maybe some work to improve there. Not every company is perfect.
I want to finish quickly here by just talking about the Agile Manifesto. All right? We know in the Agile Manifesto, we have customer collaboration over contract negotiation. I’m going to suggest that maybe make people awesome is a little bit more modern and important for our focus, okay. We want to collaborate with customers but ultimately, we want those customers to be awesome. We want our coworkers to be awesome. We want our entire ecosystem around us to be awesome.
Working software, over comprehensive documentation. That was great back in 2001. Now, we want to deliver value continuously. The bar has been raised. Responding to change over following a plan. This was incredibly important at the time because we are trying to defeat Waterfall with Agile. Now, it’s not about responding to change, it’s about experimenting and learning because we, like Paul MacCready sometimes don’t know what the problem even is.
Finally, individuals and interactions. I’ve never loved that phrase myself because interactions can be positive or negative. What does it mean to interact? I don’t know. Make safety a prerequisite. Let’s make our interactions safe, our psychological safety.
These basic four values or principles of the Manifesto, I am humbly suggesting that we consider them very useful, but historic. We consider Modern Agile to be our new goal. We’ve created ModernAgile.Org. It’s a place you can go to join this community that’s growing. If you want, there is a little spinner app so you can spin the app too, spin the wheel too just like I did today. That’s it. I think we have a couple of minutes for questions.
I believe that they may have so mics going around. Is that correct? Yes. Anyone, question? Did I answer all of your questions? Yes, question here. There. Okay. We’ll get to you.
Male: You’ve mentioned open space that you attended in Northern California. Was that a deliberate act on your part? Who put it together? How did that come about?
Joshua: First, it was at a conference in Prague. A lot of the Agile conferences have an open space environment, like this one does, Agile does. Then there are conferences that run the entire conference as open space. That would be the Agile open series of conferences. It’s two days of open space conferencing. Yeah.
Male: I really loved the way you were presenting these ideas. Something that occurred to me as you’re going was the concept of Shuhari. I was thinking that the original Agile principles and values are accessible and understandable. What you’re saying seems to be a little more esoteric, at the higher level. It’s definitely more advanced in thinking, in the sense that it’s more degrees of freedom permitting more options. Am I inappropriately applying that concept here or is it simply best to go directly to what you’re describing if you’re starting in a transformation?
Joshua: Yeah. Shuhari, I’m very familiar with that concept. I liken it to sending your kids to school. When you send them to school, you don’t say, “Hey, math and science come in grades four or five.” When you get to the fourth or fifth grade, you can start studying math and science. You start studying it early. Right?
If you’re studying it early, you’re learning even though you’re not very good at it at that time. I believe you can look at these four principles of Modern Agile and start to try to do them. Maybe you’re not going to be that great at them. Nothing prevents you from trying to do them and advance from there. I’d rather have you advance towards that goal than following some rituals and saying, “That’s my Shu stage in Shuhari.” Okay. Any others? I see a hand back there. Yeah.
Male: How’re … Hi. Thank you for speaking. In your opinion, is it only possible to get to that continuous deploying, continuous delivery endpoint if there is a lot of automation and safety nets in place to create that continuous flow of your product?
Joshua: Yeah. Great question. Do you have to have a lot of automation to do continuous delivery, continuous deployment? Actually the answer is no. You can start with an old-fashioned system that doesn’t have a lot of tests. If you change one thing to it, you have to test the heck out of that, right. You have to really test that one little thing that you’re changing, that little delta extremely well. If you can say that with confidence, “It’s okay,” you can ship that. You can deploy that continuously. It still requires a lot of testing but it doesn’t require a ton of automated tests just to get started. You don’t have to spend years creating the safety net before you begin doing continuous deployment. Sure.
Yeah?
Speaker 5: What are the love metrics to get rid of that fear?
Joshua: Okay.
Speaker 5: The fear is so bad.
Joshua: Yeah. The question is, “What are the love metrics to get rid of the fear?” Really, I’m not a psychological safety expert, I’d say. The thing I’m noticing is that management, leadership has to encourage people and start to model the desire for it to be psychologically safe. Engineers at Google, directors at Google, managers at Google, started to begin with the meetings. They began with meetings. They started with those five tips.
They said, “Let’s begin there.” They started getting much safer meetings happening and things started to spread from there. At Alcoa, they started, they say, “Keep track of anything that makes you feel unsafe. You have the authority to start to make it safer.” That was a CEO saying that though, so different from a grassroots approach.
Speaker 5: Exactly. It has to go both ways.
Joshua: It has to go both ways, yes.
Speaker 5: Okay.
Joshua: I see another one back there.
Male: Hey. Lo. About gamification.
Joshua: Yeah. Go ahead.
Male: Picking up …
Male: As a project would …
Male: Do you see gamification coming … As a ma …
Joshua: I’m having a little trouble hearing. Do you want to just come up and I’ll repeat your question?
Male: My question, do you see gamification and the first class sitting through with Modern Agile?
Joshua: Okay, do I see …
Male: Like how games are formed, games are created, mostly electronic. How do you call the games?
Joshua: The question is, “Do I see gamification as part of Modern Agile?” I am really not here to say what’s in Modern Agile, what isn’t in Modern Agile. There is no anointing of practices. If you see it fitting those four values, right? Ideally, anything you do, if it hits on all four at once, that’s really great. That’s a four-fore, you hit all four. You could go for a two-fore or a three-fore. If you can get all four with something, more power to you, so could be great.
Male: Thank you, sir.
Joshua: Any others? Yes, question?
Male: How do you think about the job description and the customer operational salary?
Joshua: So the job description, how do you think about the job description and what?
Male: Salary and operational customer.
Joshua: Yes. Job description, salary, this stuff is … There is a book called The Great Game of Business which looks a lot at this stuff, and Menlo Innovations, if you read Joy Inc., they talk about this where everyone knows what each other makes. They have an open book accounting. On their walls, you can see the cashflow coming in, the cashflow going out. It’s an incredible environment that I think you ought to look at if you’re concerned with salaries and rolls and things like that.
At Menlo, if you’re a very very very experienced person and you come to their company, you start at the bottom. Your peers decide whether you rise up. Right? Raises and getting higher up in the organization totally dependent upon your peers. It’s worth exploring. It’s worth visiting them in Ann Arbor.
Yeah. Come on. Okay. Thank you. That’s all.
