Hands-on Lessons for Advanced Topics in Entrepreneurship
Guest post by Lisa Regan, writer for The Lean Startup Conference.
We’ve posted the full program for The Lean Startup Conference, and it includes more than three days of events for Gold pass holders and six days of events for VIP pass holders. We wanted to give you a rundown of what’s in store, along with particular insight into two of the workshops we’re most excited to have lined up for Gold and VIP attendees—one session with Jez Humble on implementing continuous delivery and one with Alistair Croll on Lean analytics for corporate entrepreneurs.
Here’s an overview of all the goodies:
We’ve structured the workshops around last year’s feedback, in which you suggested that you wanted more information about specific practices and contexts. Many workshops thus teach you to apply specific Lean Startup methods: creating experiments, interviewing customers, optimizing pricing, and innovation accounting. For example, Janice Fraser will run a workshop on Build, Measure, Learn in which she teaches experimentation, taking you through the entire process of designing an experiment, and then letting you learn in the field what actually works. Jonathan Irwin will lead a workshop on advanced interview skills, including the different kinds of customer interviews, how to develop questions, and how to apply the answers to an actual decision around a product. Justin Wilcox will teach you how to find the optimum price for a product without sacrificing conversions with methods like A/B testing, crowdfunding, “real customers,” and actual transactions. Ash Maurya will break down one of the most frequently asked-about and misunderstood elements of Lean Startup--innovation accounting. By the end of his workshop, you will know how to apply innovation accounting to truly track the progress of your product. And Don Reinertsen will teach you how to calculate and weigh the implications of Cost of Delay—the monetary value of a week of cycle time for experiments—information that will change the way your organization runs experiments.
We’ve also had many questions about the how-to of implementing Lean Startup at companies that are either mid-sized or large—not startups, but organizations that would like to harness startup energy to create a culture of experimentation. So, we’ve put together a set of workshops for teaching methods to bring Lean Startup to big companies. For instance, Brant Cooper will lead you through applying Lean Startup in HR, IT and finance teams. Alistair Croll will lead a session on Lean analytics for intrapreneurs—from introducing never-before-seen case studies to tracking a product through its entire development and demonstrating which data and metrics are useful in what kinds of situations. Patrick Sheridan will lead a workshop on bringing mobile development to established companies, especially for execs and team leaders.
We want these workshops to be true hands-on laboratories, in which you (and your team) can get a complete training in a Lean Startup method, and leave feeling confident putting it into practice immediately. To demonstrate the kind of thing we have in mind, we spoke to Jez Humble, who will lead a workshop, Continuous Delivery: Deploy Safer, Learn Faster. Jez, who is a principal at ThoughtWorks, co-author of the Jolt Award-winning Continuous Delivery and the forthcoming Lean Enterprise, will address one of the thorniest areas of Lean Startup: how to reduce cycle times by constantly releasing updated software to customers and quickly responding to their feedback. We asked him a few questions to learn about continuous delivery, why it’s useful, and what engineers and management need to do to implement it.
LSC: One of the biggest fears people have about a continuous deployment environment is that it introduces more risk to engineering. How do you address that?
People imagine that continuous deployment means taking the nasty, painful, risky deployment process that they are familiar with and doing it more frequently. That would indeed be madness, but fortunately, that’s not what’s being proposed.
Teams who practice continuous delivery do four things very differently. First, we design the software so that it’s easy to deploy it in an automated, push-button fashion (this can be done even with very complex systems, given sufficient thought). Second, we make sure it’s easy to detect and reject bad changes before they go live, using a deployment pipeline. Third, we make sure it’s easy to remediate any problems that do make it into production, using techniques such as dark launching, feature toggles, blue-green deployments, and canary releases. Thus we reduce the risk of deployments.
All this enables the fourth element—working in small batches. Continuous deployment means more frequent releases, but crucially, these are of much smaller changesets. This means it’s easier to find the change that caused the problem and easier to remediate it. Continuous deployment doesn’t mean doing a multi-hour release of several weeks’ worth of code multiple times a day. It means doing an automated, push-button release of a tiny amount of change multiple times a day.
LSC: Continuous delivery involves a set of frameworks that you can put in place over time. Which are the most important pieces, and which can you delay? Or, how would a company decide in what order to introduce them?
Which to implement and the order you choose depends on where you’re starting. For example, in an enterprise context, moving to continuous delivery can mean making significant architectural changes and changing the culture of development, testing, and operations teams. Needless to say, this is a slow and complex process.
The key is to find ways to achieve measurable improvement quickly and then iterate. Working towards a smoother, lower-risk and more frequent deployment process is part of continuous improvement. You’re never “done,” because as systems grow and change you’ll need to continue to ensure that your test and deployment framework stays fast and maintainable, that architectural decisions support the testability and deployability of your systems, and that the people growing and running these systems collaborate effectively.
Often the biggest problem is building up trust between the developers and the people who deploy and operate the systems. This requires that developers take responsibility for the deployability and operability of the systems they build, seeking out and acting on feedback by—for example—going on rotation for pager duty. It’s incumbent on devs to make sure their code is well-tested and easy to deploy before asking ops to deploy it more frequently. Equally, ops needs to support dev by making sure they have sufficient access to production-like testing environments.
In many cases the best place to start is having devs work off mainline in version control and practice continuous integration—working in small batches off trunk and ensuring all changes pass automated tests—to make sure their code is always in a known good state.
LSC: What kind of team structure do you recommend for companies using continuous delivery? And what, if anything, should managers do differently to get the most out of this approach?
As Mike Rother points out in Toyota Kata, what’s decisive is not the organizational structure but the mindset of the people in the organization. For continuous delivery to work, everybody has to take responsibility for the customer experience. It can’t work if developers have the attitude that they’re done once their code works on their machine and it’s checked into version control. If there’s a problem in production, developers need to own it.
Admittedly, organizational silos contribute to a lack of ownership, because they abstract people away from the consequences of their actions. Thus it’s important to create and establish fast feedback loops so we can measure the effects of our changes. We need to be able to answer questions like: “Did the change I made degrade performance?” or “Did the feature I just built actually increase revenue?” Continuous deployment makes a huge difference because when you work in small batches it becomes much easier to discern cause and effect. Fortunately, that is enormously empowering—nobody who’s actually experienced continuous deployment wants to go back to the old way of doing things.
Managers—like everyone in the organization—need to do a lot of things differently. We need to stop talking about requirements and start thinking in terms of running experiments to test our hypotheses about what users might find valuable. That’s a huge—and often challenging—change for product people. On the engineering side, we need to stop optimizing for cost and utilization and start focusing on cycle time instead. In operations, we need to think about stability in terms of time to restore service rather than time between failures.
Most important, we need to understand that it’s OK to fail. Instead of trying to find out who to blame when things go wrong, we need to understand that complex systems inevitably drift into failure. Trying to remove risk inevitably kills innovation, and creates an environment in which nobody is interested in trying to improve things in case they get blamed when something goes wrong. That is one of the biggest problems in enterprises.
--
During our recent webcast on Lean analytics with Alistair Croll and Ben Yoskovitz, co-authors of Lean Analytics, they discussed some of the topics Alistair will cover in his December 11 conference workshop. Here are a couple of highlights:
Alistair, on the fact that every company can experiment and measure results: I’ll give you two examples, a big one and one very small. I have a coffee shop down the street that has tip jars out, and they put out a question, and they look at which one got the most tips. And it is great for their tips, and they can ask people, which of these two products would you like us to serve? That’s a survey, right? And then at the other end of the spectrum you have Walmart, and Walmart has this campaign called Get On the Shelf, where people nominate products, and then Walmart has votes and tests them and it’s essentially a Kickstarter for shelf space at Walmart. Both of those are forms of experimentation. Once upon a time in the 1950s, the average lifespan of a company on the S&P 500 was 58 years, I think, and in 2013, it’s down to about 13 years. People say startups have nothing to lose, but big companies have everything to lose. So I think there is a recognition that we need to start disrupting more and running more experiments, taking more risks, focusing on learning and framing new products as a way of finding things out, chasing the data instead of just accepting it.
Alistair, on the difference between a chase-that-data method and a cover-your-ass approach to analytics: We talked to Jana Eggers, who helped set up the innovation lab at Intuit and also was at Spreadshirt and Blackbaud. And she told us that at Spreadshirt, they use the Net Promoter score as a measurement of satisfaction, and they track it by country and region. One day, they saw that Norway just fell off the map. So most companies would go: “Oh, I guess Norwegians just don’t like T-shirts,” and they leave it at that. Jana’s whole thing was, “We’re going to chase that down and find what the story is.” So they called the Norwegian customs office, and they found that Norway a week before had consolidated all of its post offices. And as a result of that, customs support had gone down. By contacting customs in Norway, they were able to work out how to label things to actually get them delivered a little faster. So one of the problems that a lot of people mention is that companies are data-obsessed—but they are not chasing the data. They look at the data as a way of covering their butts, you know, “We’re tracking that data,’ so it’s more of a cover-your-ass methodology, and the reality is you need to chase data.
Ben, on introducing Lean analytics to a big company: The example I think about is Comcast. I was asking how they got Lean into the company, and the answer was: “We just started.” If somebody comes to you with a project, you have to do the project, and you have to budget the project. But instead of saying: “Let’s plan this whole thing out and build the whole thing before we realize if anyone wants it or not,” step one is: “Let’s go talk to customers.” And it wasn’t making a big deal out of it, it wasn’t saying, “We need to change everything in our company.” It wasn’t looking at what these cool startups are doing so we’re going to go apply that into our business, it wasn’t anything along those lines. It was simply: “Oh, we can’t fail if we just talk to customers. Let’s just see what happens.” And then everyone said: “I guess this is the process we’re applying to this project,” and they were set to go. You can sneak Lean Startup or sneak Lean analytics or a combination of both by just starting as simply as possible.
--
Our December 11 workshops will give you deep, practical advice. Gold and VIP pass holders can attend workshops, and there are a limited number available. Register today to get yours. If you're already registered and would like to upgrade to the VIP or Gold Pass, email info@leanstartup.co by November 22 and we'll send you a link to upgrade.
We’ve posted the full program for The Lean Startup Conference, and it includes more than three days of events for Gold pass holders and six days of events for VIP pass holders. We wanted to give you a rundown of what’s in store, along with particular insight into two of the workshops we’re most excited to have lined up for Gold and VIP attendees—one session with Jez Humble on implementing continuous delivery and one with Alistair Croll on Lean analytics for corporate entrepreneurs.
Here’s an overview of all the goodies:
- During the day on December 8, VIP pass holders can attend Leancamp, a full-day unconference rich with chances to meet other people and talk through ideas.
- On the evening of December 8, Ignite Lean Startup kicks off the conference. Each brave presenter gets five minutes and 20 slides—which advance automatically every 15 seconds. This event is open to everyone, but the venue is small, and VIP pass holders get guaranteed seating.
- On December 9 and 10, dozens of talks, mentoring opportunities and new networking events comprise the main days of The Lean Startup Conference. VIP pass holders get priority seating for keynotes and invitations to private lunches.
- On December 11—for VIP and Gold pass holders only—we’re holding a day of hands-on workshops with top Lean Startup experts and private startup site visits around San Francisco. The site visits include stops at Square (the payments startup founded by Twitter co-creator Jack Dorsey), WeWork Soma (an amazing co-working space) and Pivotal Labs (leaders in Lean and Agile consulting), along with one more super-interesting location we’ll announce shortly.
- Starting on the evening of December 11 and running through December 13—for VIP pass holders only—we’re partnering with UP Global’s Startup Weekend to offer a two-day Lean Startup immersion program, specially designed to teach you how to put Lean Startup theory directly into practice.
We’ve structured the workshops around last year’s feedback, in which you suggested that you wanted more information about specific practices and contexts. Many workshops thus teach you to apply specific Lean Startup methods: creating experiments, interviewing customers, optimizing pricing, and innovation accounting. For example, Janice Fraser will run a workshop on Build, Measure, Learn in which she teaches experimentation, taking you through the entire process of designing an experiment, and then letting you learn in the field what actually works. Jonathan Irwin will lead a workshop on advanced interview skills, including the different kinds of customer interviews, how to develop questions, and how to apply the answers to an actual decision around a product. Justin Wilcox will teach you how to find the optimum price for a product without sacrificing conversions with methods like A/B testing, crowdfunding, “real customers,” and actual transactions. Ash Maurya will break down one of the most frequently asked-about and misunderstood elements of Lean Startup--innovation accounting. By the end of his workshop, you will know how to apply innovation accounting to truly track the progress of your product. And Don Reinertsen will teach you how to calculate and weigh the implications of Cost of Delay—the monetary value of a week of cycle time for experiments—information that will change the way your organization runs experiments.
We’ve also had many questions about the how-to of implementing Lean Startup at companies that are either mid-sized or large—not startups, but organizations that would like to harness startup energy to create a culture of experimentation. So, we’ve put together a set of workshops for teaching methods to bring Lean Startup to big companies. For instance, Brant Cooper will lead you through applying Lean Startup in HR, IT and finance teams. Alistair Croll will lead a session on Lean analytics for intrapreneurs—from introducing never-before-seen case studies to tracking a product through its entire development and demonstrating which data and metrics are useful in what kinds of situations. Patrick Sheridan will lead a workshop on bringing mobile development to established companies, especially for execs and team leaders.
We want these workshops to be true hands-on laboratories, in which you (and your team) can get a complete training in a Lean Startup method, and leave feeling confident putting it into practice immediately. To demonstrate the kind of thing we have in mind, we spoke to Jez Humble, who will lead a workshop, Continuous Delivery: Deploy Safer, Learn Faster. Jez, who is a principal at ThoughtWorks, co-author of the Jolt Award-winning Continuous Delivery and the forthcoming Lean Enterprise, will address one of the thorniest areas of Lean Startup: how to reduce cycle times by constantly releasing updated software to customers and quickly responding to their feedback. We asked him a few questions to learn about continuous delivery, why it’s useful, and what engineers and management need to do to implement it.
LSC: One of the biggest fears people have about a continuous deployment environment is that it introduces more risk to engineering. How do you address that?
People imagine that continuous deployment means taking the nasty, painful, risky deployment process that they are familiar with and doing it more frequently. That would indeed be madness, but fortunately, that’s not what’s being proposed.
Teams who practice continuous delivery do four things very differently. First, we design the software so that it’s easy to deploy it in an automated, push-button fashion (this can be done even with very complex systems, given sufficient thought). Second, we make sure it’s easy to detect and reject bad changes before they go live, using a deployment pipeline. Third, we make sure it’s easy to remediate any problems that do make it into production, using techniques such as dark launching, feature toggles, blue-green deployments, and canary releases. Thus we reduce the risk of deployments.
All this enables the fourth element—working in small batches. Continuous deployment means more frequent releases, but crucially, these are of much smaller changesets. This means it’s easier to find the change that caused the problem and easier to remediate it. Continuous deployment doesn’t mean doing a multi-hour release of several weeks’ worth of code multiple times a day. It means doing an automated, push-button release of a tiny amount of change multiple times a day.
LSC: Continuous delivery involves a set of frameworks that you can put in place over time. Which are the most important pieces, and which can you delay? Or, how would a company decide in what order to introduce them?
Which to implement and the order you choose depends on where you’re starting. For example, in an enterprise context, moving to continuous delivery can mean making significant architectural changes and changing the culture of development, testing, and operations teams. Needless to say, this is a slow and complex process.
The key is to find ways to achieve measurable improvement quickly and then iterate. Working towards a smoother, lower-risk and more frequent deployment process is part of continuous improvement. You’re never “done,” because as systems grow and change you’ll need to continue to ensure that your test and deployment framework stays fast and maintainable, that architectural decisions support the testability and deployability of your systems, and that the people growing and running these systems collaborate effectively.
Often the biggest problem is building up trust between the developers and the people who deploy and operate the systems. This requires that developers take responsibility for the deployability and operability of the systems they build, seeking out and acting on feedback by—for example—going on rotation for pager duty. It’s incumbent on devs to make sure their code is well-tested and easy to deploy before asking ops to deploy it more frequently. Equally, ops needs to support dev by making sure they have sufficient access to production-like testing environments.
In many cases the best place to start is having devs work off mainline in version control and practice continuous integration—working in small batches off trunk and ensuring all changes pass automated tests—to make sure their code is always in a known good state.
LSC: What kind of team structure do you recommend for companies using continuous delivery? And what, if anything, should managers do differently to get the most out of this approach?
As Mike Rother points out in Toyota Kata, what’s decisive is not the organizational structure but the mindset of the people in the organization. For continuous delivery to work, everybody has to take responsibility for the customer experience. It can’t work if developers have the attitude that they’re done once their code works on their machine and it’s checked into version control. If there’s a problem in production, developers need to own it.
Admittedly, organizational silos contribute to a lack of ownership, because they abstract people away from the consequences of their actions. Thus it’s important to create and establish fast feedback loops so we can measure the effects of our changes. We need to be able to answer questions like: “Did the change I made degrade performance?” or “Did the feature I just built actually increase revenue?” Continuous deployment makes a huge difference because when you work in small batches it becomes much easier to discern cause and effect. Fortunately, that is enormously empowering—nobody who’s actually experienced continuous deployment wants to go back to the old way of doing things.
Managers—like everyone in the organization—need to do a lot of things differently. We need to stop talking about requirements and start thinking in terms of running experiments to test our hypotheses about what users might find valuable. That’s a huge—and often challenging—change for product people. On the engineering side, we need to stop optimizing for cost and utilization and start focusing on cycle time instead. In operations, we need to think about stability in terms of time to restore service rather than time between failures.
Most important, we need to understand that it’s OK to fail. Instead of trying to find out who to blame when things go wrong, we need to understand that complex systems inevitably drift into failure. Trying to remove risk inevitably kills innovation, and creates an environment in which nobody is interested in trying to improve things in case they get blamed when something goes wrong. That is one of the biggest problems in enterprises.
--
During our recent webcast on Lean analytics with Alistair Croll and Ben Yoskovitz, co-authors of Lean Analytics, they discussed some of the topics Alistair will cover in his December 11 conference workshop. Here are a couple of highlights:
Alistair, on the fact that every company can experiment and measure results: I’ll give you two examples, a big one and one very small. I have a coffee shop down the street that has tip jars out, and they put out a question, and they look at which one got the most tips. And it is great for their tips, and they can ask people, which of these two products would you like us to serve? That’s a survey, right? And then at the other end of the spectrum you have Walmart, and Walmart has this campaign called Get On the Shelf, where people nominate products, and then Walmart has votes and tests them and it’s essentially a Kickstarter for shelf space at Walmart. Both of those are forms of experimentation. Once upon a time in the 1950s, the average lifespan of a company on the S&P 500 was 58 years, I think, and in 2013, it’s down to about 13 years. People say startups have nothing to lose, but big companies have everything to lose. So I think there is a recognition that we need to start disrupting more and running more experiments, taking more risks, focusing on learning and framing new products as a way of finding things out, chasing the data instead of just accepting it.
Alistair, on the difference between a chase-that-data method and a cover-your-ass approach to analytics: We talked to Jana Eggers, who helped set up the innovation lab at Intuit and also was at Spreadshirt and Blackbaud. And she told us that at Spreadshirt, they use the Net Promoter score as a measurement of satisfaction, and they track it by country and region. One day, they saw that Norway just fell off the map. So most companies would go: “Oh, I guess Norwegians just don’t like T-shirts,” and they leave it at that. Jana’s whole thing was, “We’re going to chase that down and find what the story is.” So they called the Norwegian customs office, and they found that Norway a week before had consolidated all of its post offices. And as a result of that, customs support had gone down. By contacting customs in Norway, they were able to work out how to label things to actually get them delivered a little faster. So one of the problems that a lot of people mention is that companies are data-obsessed—but they are not chasing the data. They look at the data as a way of covering their butts, you know, “We’re tracking that data,’ so it’s more of a cover-your-ass methodology, and the reality is you need to chase data.
Ben, on introducing Lean analytics to a big company: The example I think about is Comcast. I was asking how they got Lean into the company, and the answer was: “We just started.” If somebody comes to you with a project, you have to do the project, and you have to budget the project. But instead of saying: “Let’s plan this whole thing out and build the whole thing before we realize if anyone wants it or not,” step one is: “Let’s go talk to customers.” And it wasn’t making a big deal out of it, it wasn’t saying, “We need to change everything in our company.” It wasn’t looking at what these cool startups are doing so we’re going to go apply that into our business, it wasn’t anything along those lines. It was simply: “Oh, we can’t fail if we just talk to customers. Let’s just see what happens.” And then everyone said: “I guess this is the process we’re applying to this project,” and they were set to go. You can sneak Lean Startup or sneak Lean analytics or a combination of both by just starting as simply as possible.
--
Our December 11 workshops will give you deep, practical advice. Gold and VIP pass holders can attend workshops, and there are a limited number available. Register today to get yours. If you're already registered and would like to upgrade to the VIP or Gold Pass, email info@leanstartup.co by November 22 and we'll send you a link to upgrade.
0 comments:
welcome to my blog. please write some comment about this article ^_^