Scaling Product Development at a

2,623 views

Published on

IMVU is sometimes referred to as the original 'Lean Startup', having successfully blended Agile methodologies with Customer Development methodologies. This lecture focuses on IMVU's product development process, and the hard won learning which has allowed it to evolve and scale with company growth. Topics include foundations for successful Scrum implementation in the organization, specific Agile methodologies used and why, detailed description of the Scrum team calendar and planning process, and how IMVU uses retrospectives, postmortems, and '5 Whys' to continuously evolve the product development process and ensure Engineering delivers successfully for customers and the Product Management organization.

Published in: Technology, Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,623
On SlideShare
0
From Embeds
0
Number of Embeds
828
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • I’ve got some questions for you:How many of you are part of a product team building great stuff for customers? Now…
  • …does anyone have one product development tactic you use that works consistently to help your team meet its goals and deliver great stuff to customers, every time and for every project? I would like that, because it would be great to know that there is tactic, or even a set of tactics or a process—that can lead my team to success every time.
  • But I can’t think of even onethat I would count on to work every time, not amidst all the changing conditions of a dynamic product and business. What I would bet my money on is a winning…
  • …strategy, one you can use to maximize your team’s chances of success over time of delivering great features to your customers.Today I’ll share one of the strategies that we use at IMVU.
  • I’m going to review a lot of material today, so to make a couple things more memorable, I’ll reference two of my favorite things: pizza and maps.
  • Today IMVU is asocial entertainment product where our customersuse 3D avatars to meet people, chat, create cool stuff—AKA UGC--, and play games with their friends.
  • Today IMVU is asocial entertainment product where our customersuse 3D avatars to meet people, chat, create cool stuff—AKA UGC--, and play games with their friends.
  • But we started as an add-on…
  • …to products like AOL Instant Messenger, adding 3D avatars to text-based instant messaging. Unfortunately for us, we failed!
  • It turned out that we built something our customers didn’t want. But we listened to customer feedback, and began changing our product to suit their needs.
  • We were doing the first parts of Customer Development: Customer Discovery and Customer Validation.Customer Discovery: ensuring the product solves a problem for a group of customersCustomer Validation: Ensuring that group of customers is big enough to build a business
  • And our product development process involved one big weekly meeting to update each other on project status. Our development cycles were 2 months long.
  • We were trying to find a recipe for a product people would like enough to buy, and then build a business on top of that. The team was small and well coordinated, and it worked!
  • After many trials, we found a decent recipe! It wasn’t the best in the world, but it was certainly edible.
  • And the numbers looked pretty good, too… so we thought we could run with this recipe, and we decided to scale it. We thought we could take lots of this dough, this sauce, and this cheese and just make a lot of it… but we didn’t think about changing the recipe to suit this scaling plan, and
  • But clearly, if our goal was to scale, we didn’t do it very well.
  • Something wasn’t working.As it turns out…
  • What got you here won’t always get you there.
  • When you take the recipe and try to scale it up, you end up with something mediocre. You can’t just multiply the amounts of ingredients. You have to adjust the ratios in your recipe, often the cooking temperature and time, sometimes the cooking method…
  • When you take the recipe and try to scale it up, you end up with something mediocre. You can’t just multiply the amounts of ingredients. You have to adjust the ratios in your recipe, often the cooking temperature and time, sometimes the cooking method…So what happened in our case? We had one person in charge of the sauce, one person in charge of the cheese, and another person in charge of the doughEach of those people thought they could manage their part of the product recipe separately and come up with a bigger version of the original pizza. But we didn’t have a single person in charge of how the entire pizza recipe would come together into something that people would really like and want to pay for. AND, we were GROWING!
  • And the product development process that worked for a small, focused team
  • …wasn’t working for our larger and fast-growing team.
  • Here’s a way to visualize what was going on from our customers’ perspective: I don’t know how many of you have used IMVU, but most of you probably know iTunes…Imagine trying to buy a music track, and instead of the simple process you’re used to…
  • …aweb browser launches, obscures the iTunes UI, and forces you through a web-based purchase process, which even if you complete successfully, doesn’t leave you in a position to listen to the track you just purchased.This is a situation our customers were intimately familiar with …
  • This is the previous version of the IMVU 3D chat client. You can see we’ve got the ability to have multiple 3D chat’s happening, cool… and we’ve got a buddy list…okay, and wait—what’s that?
  • An inventory attached to the buddy list? Well that feels sort of “bolted on”, but alright… So let’s say that you’re chatting and you want to buy a snazzy new shirt: first of all, how do you think you would buy something here? Anyone? If you manage to find the “shop catalog” button—bully for you! Now hopefully your friends won’t be too insulted as you leave them, perhaps permanently, and we pop a web browser right over the top of the IMVU chat client UI
  • Oops. Many of our customers got lost at this point, never to find there way back into our core experience.
  • We were held prisoner by a couple of things.
  • Our technology was standing in the way of us being able to respond to our customers—due to accumulated technical debt from our early “discovery” mode product development.
  • And fixing our UI infrastructure was a project that would require a large, coordinated effort that our existing PROCESS couldn’t support.
  • Sort of a Catch-22.
  • Here are some of the other issues and problems:Lack of strong, consistent product ownershipToo much focus on individual business metricsInability to make big feature changes—no one product owner or team had enough resources to make a big change. No coherent full-product visionWe’d outgrown our product development process
  • It all might have been comic…if it hadn’t been so tragic for our customers and our business.
  • So we decided to try something new and CRAZY!
  • LEARN FROM OUR MISTAKES!
  • We consciously took stock of our situation, and decided to make some big changes based on our experience.Two importantchanges were 1) we hired a one person to be responsible for the entire customer experience, with responsibility and a mandate to make big changes, and2) We updated our product development process.
  • We decided to usethe same Lean Startup philosophy that grew the company in the early days to improve and scale our development process. This is the Build Measure Learn loop.We figured, if it works for building cars and our first 3d Chat client, there’s no reason it shouldn’t work for building an efficient software product development team as well.
  • So the plan was to build, measure, and learn as quickly as possible, and incorporate new innovations into our process each sprint.
  • We ravamped the UI infrastructure that was so rife with technical debt, so we could build new UI quickly and efficiently using HTML and JavaScript.
  • And the same teams that were mired before become what our product owners now call the most productive teams they’ve ever worked with.
  • And we did it! We found a great recipe…And our customers loved it.
  • And the numbers look pretty good, too.
  • So how did we do it? We made a lot of changes in the company; here are some of the changes to our product development process.
  • Our product development process is built on a 3-week sprint cycleRemember the build-measure-learn loop? We’ve found that 3 week sprints are ideal for our teams.
  • Scrum facilitates face to face communication, and the daily standup is an opportunity to re-emphasize our commitments to each other and to the team. We say what we accomplished yesterday, what we are committing to get done today, and whether we are blocked in any way. We also take time for follow-up discussions on any topic people want to bring up.Everyone leaves the meeting knowing the exact status of the projects we’re working on.We do this in 15 minutes or less per day.
  • Planning meeting…
  • Artifacts – a shared task board
  • Artifacts – a burndown chart for tracking progress
  • Let’s talk about some of the tactics we use successfully at IMVU
  • Standardize.Shipping containers are all the same size. This is because they stack better, and are easier to manage efficiently.But our teams were all doing something different…
  • Wefound that when our teams were doing things their own way, they didn’t work together that well. Team workflows were too different; it was hard to swap team members and manage different process flows, and it was just harder for everyone to understand what we were working on, and why.So we started with a standardized Scrum process, and now we mange the ongoing evolution of that process.Then it was… Team members understand processes for any team Easy to swap team members Easy to coordinate schedules Easier to share best practices
  • Changing and evolving your process, is, by the way, in conflict with most dogmatic or zealous approaches to project management.So we avoid dogma.For example, we decided that locking down the sprint backlog at the start of the sprint wasn’t working for us. Sometimes we need to react quickly to marketing needs or prioritize critical work. Unexpected things happen, and Scrum—or any other methodology--practiced dogmatically, doesn’t accommodate that very well.Given that we’re committed to continuous improvement of our process, we avoid dogma at all costs.
  • So we call attention to changes in the sprint backlog daily in scrum and decide as team whether to accept the new work into the sprint.
  • Focused Meeting of Key StakeholdersSolution for a successful planning meetingProduct Owner, QA, Tech Lead, Designer pre-plan togetherReview draft design documents Incorporate different viewpoints and approaches Then revise to align documents
  • Ground Rules for Planning MeetingsWe want our teams to have a shared understanding of the sprint projects Full team reviews detailed project planning Planning takes 2-6 hours Discussion, disagreement, new ideas, learning Project scope changes Detailed: we dive into the code and project designsFoster engagement during planningNo laptops or cell phonesNo side conversations.Share the keyboard: take turns driving the meetingTake breaks, bring in food and refreshments
  • Something that deserves special mention is STAKEHOLDER AGREEMENTWe found that time spent to complete tasks was often different than planned, making sprint success difficult to predictSolution: two engineers + technical lead must agree on task durationFosters engagement, discussion, and debate, and the result is a deeper understanding of task requirementsAccomplishes the same engagement as using story points and playing planning poker.
  • And the doors are locked and all the cold Coke Zero is held outside, until they agree. ;)
  • We’ve found recently that a good target for team size is about 4 engineers per team.Communication overhead increases quickly as you add people, and since scrum is all about lightweight, face-to-face communication, adding team members can quickly cause unforeseen problems.We’ve found that about 4 engineers is the sweet spot for optimizing our ability to get things done efficiently and with high quality.
  • However, we learned that the hard way, but in 2 easy steps:We created a great process…
  • 2) We followed our process, and got into a comfortable routine.We gradually increased our team size, and incorporated new practices to accommodate for subtle changes that were happeningTeam made an optimization to reduce interruptions, based on a Best Practice from another team, allowing two team members to only fix broken tests (we use TDD).Other team members were writing feature code more efficiently; fewer interruptions.
  • Oops.Things got bad slowlyOne group created problems that another group had to solveNo immediate feedback loopWe failed to understand the impact of an underlying infrastructure problem Team too big—happened gradually
  • Learn from your mistakes (and your successes)Pay attention to what works and what doesn’t Created best practice for team size: max 4 eng Began using story points Objective, high-level measure of velocity Early signal of success/failure, even if team “seems” fine Faster response time
  • Over time you might develop some ALWAYS’SWhat is an always’s you ask? These are things we do for every project, always.Remind yourselves about these—write them on the whiteboard during your planning meeting!(Planning Assumptions on the whiteboard)
  • We also write our planning assumptions on the whiteboard.We make our assumptions publicThis Reduce surprises, ensures engagement, helps catch errors.Making these assumptions explicit means it’s harder to forget planned vacations, conferences, and other events that might affect planning. It also sets expectations for how much time each engineer will be contributing to achieving the team goals that sprint.
  • This is all part of our Planning Technology
  • This is one of our early scrum task boards.
  • A later version of our scrum task board:BiggerPainter’s tape5 columns (Added QA + “New”)“New” column: We realized we were in charge of our destiny, and that we wanted to accommodate new work coming into the sprint
  • In planning, we needed to refer to the old board AND make a new board.Voila: the temporary task board
  • We spared no expense and found removable artists tape and black foam core…And this board has some *sweet* features:“New” columnProject Follow-up LanePhysical size limits number of storiesEasy to add/remove tasksEasy to meet, collaborate, plan workEasy to move to meeting roomsEasy to buildHard to work with if you are remote!
  • An online board is helpful with people working remotely from home or other locations
  • Context Matters: Some of our process works because of the particular context we have at a given time.Context changes! Some of our greatest failures result from following our process. You have to know when to deviate from your process. You have to always remember that you are in control, you are driving.
  • A map can be a useful guide, but it is not a substitute for paying attention to what is going on. If you follow this map without thinking about it, you might run into problems.Process is like a map.Your process is not a replacement for being engaged and paying attention!
  • Plan your route! Ensure that you are headed to the right destination. What your process or plan tells you is the right offramp, may not be.Process is not a substitute for engagement.Engage!Be conscious!Expect the unexpected.Change your process in subtle ways that get people to engage…Start using story points, for example…Any change you make will create a problem for the team to solve, and require people to re-engage
  • So What Did We Learn?
  • Scaling Product Development at a

    1. 1. Scaling Product Development at a "Lean Startup": Agile at IMVU<br />Tweet this talk! #imvugdc<br />James Birchler (@jamesbirchler)Engineering DirectorIMVU, Inc.<br />GDC Online, Oct. 5-8, 2010<br />
    2. 2. I’ve got some questions for you:<br />How many of you are part of a product team building great stuff for customers? <br />Now… <br />…does anyone have one product development tactic you use that works consistently to help your team meet its goals and deliver great stuff to customers, every time and for every project? <br />I would like that, because it would be great to know that there is tactic, or even a set of tactics or a process—that can lead my team to success every time. <br />But I can’t think of even one that I would count on to work every time, not amidst all the changing conditions of a dynamic product and business. <br />What I would bet my money on is a winning…<br />…strategy, one you can use to maximize your team’s chances of success over time of delivering great features to your customers.<br />Today I’ll share one of the strategies that we use at IMVU.<br />I’m going to review a lot of material today, so to make a couple things more memorable, I’ll reference two of my favorite things: pizza and maps. <br />Today IMVU is a social entertainment product where our customers use 3D avatars to meet people, chat, create cool stuff—AKA UGC--, and play games with their friends. <br />But we started as an add-on…<br />…to products like AOL Instant Messenger, adding 3D avatars to text-based instant messaging. Unfortunately for us, we failed! <br />It turned out that we built something our customers didn’t want. <br />But we listened to customer feedback, and began changing our product to suit their needs. <br />We were doing the first parts of Customer Development: Customer Discovery and Customer Validation.<br />Customer Discovery: ensuring the product solves a problem for a group of customers<br />Customer Validation: Ensuring that group of customers is big enough to build a business <br />And our product development process involved one big weekly meeting to update each other on project status. Our development cycles were 2 months long.<br />We were trying to find a recipe for a product people would like enough to buy, and then build a business on top of that. <br />The team was small and well coordinated, and it worked!<br />After many trials, we found a decent recipe! <br />It wasn’t the best in the world, but it was certainly edible. <br />And the numbers looked pretty good, too… so we thought we could run with this recipe, and we decided to scale it. <br />We thought we could take lots of this dough, this sauce, and this cheese and just make a lot of it… but we didn’t think about changing the recipe to suit this scaling plan, and <br />But clearly, if our goal was to scale, we didn’t do it very well. <br />Something wasn’t working.<br />As it turns out… <br />What got you here won’t always get you there.<br />When you take the recipe and try to scale it up, you end up with something mediocre. You can’t just multiply the amounts of ingredients. You have to adjust the ratios in your recipe, often the cooking temperature and time, sometimes the cooking method…<br />So what happened in our case? <br />We had one person in charge of the sauce, one person in charge of the cheese, and another person in charge of the dough<br />Each of those people thought they could manage their part of the product recipe separately and come up with a bigger version of the original pizza. <br />But we didn’t have a single person in charge of how the entire pizza recipe would come together into something that people would really like and want to pay for. <br />AND, we were GROWING!<br />And the product development process that worked for a small, focused team …wasn’t working for our larger and fast-growing team.<br />Here’s a way to visualize what was going on from our customers’ perspective: I don’t know how many of you have used IMVU, but most of you probably know iTunes…<br />Imagine trying to buy a music track, and instead of the simple process you’re used to… …a web browser launches, obscures the iTunes UI, and forces you through a web-based purchase process, which even if you complete successfully, doesn’t leave you in a position to listen to the track you just purchased.<br />This is a situation our customers were intimately familiar with …<br />This is the previous version of the IMVU 3D chat client. You can see we’ve got the ability to have multiple 3D chat’s happening, cool… and we’ve got a buddy list…okay, and wait—what’s that? <br />An inventory attached to the buddy list? Well that feels sort of “bolted on”, but alright… So let’s say that you’re chatting and you want to buy a snazzy new shirt: first of all, how do you think you would buy something here? Anyone? If you manage to find the “shop catalog” button—bully for you! Now hopefully your friends won’t be too insulted as you leave them, perhaps permanently, and we pop a web browser right over the top of the IMVU chat client UI <br />Oops. Many of our customers got lost at this point, never to find there way back into our core experience. <br />We were held prisoner by a couple of things.<br />Our technology was standing in the way of us being able to respond to our customers—due to accumulated technical debt from our early “discovery” mode product development. <br />And fixing our UI infrastructure was a project that would require a large, coordinated effort that our existing PROCESS couldn’t support. <br />Sort of a Catch-22.<br /><ul><li>Here are some of the other issues and problems:
    3. 3. Lack of strong, consistent product ownership
    4. 4. Too much focus on individual business metrics
    5. 5. Inability to make big feature changes—no one product owner or team had enough resources to make a big change.
    6. 6. No coherent full-product vision
    7. 7. We’d outgrown our product development process</li></ul>It all might have been comic…if it hadn’t been so tragic for our customers and our business. <br />So we decided to try something new and CRAZY! <br />LEARN FROM OUR MISTAKES! <br />We consciously took stock of our situation, and decided to make some big changes based on our experience.<br />Two important changes were 1) we hired a one person to be responsible for the entire customer experience, with responsibility and a mandate to make big changes, and<br />2) We updated our product development process. <br />We decided to use the same Lean Startup philosophy that grew the company in the early days to improve and scale our development process. <br />This is the Build Measure Learn loop. <br />We figured, if it works for building cars and our first 3d Chat client, there’s no reason it shouldn’t work for building an efficient software product development team as well. <br />So the plan was to build, measure, and learn as quickly as possible, and incorporate new innovations into our process each sprint. <br />We ravamped the UI infrastructure that was so rife with technical debt, so we could build new UI quickly and efficiently using HTML and JavaScript.<br />And the same teams that were mired before become what our product owners now call the most productive teams they’ve ever worked with. <br />And we did it! We found a great recipe…<br />And our customers loved it. <br />And the numbers look pretty good, too. <br />So how did we do it? We made a lot of changes in the company; here are some of the changes to our product development process. <br />Our product development process is built on a 3-week sprint cycle<br />Remember the build-measure-learn loop? We’ve found that 3 week sprints are ideal for our teams.<br />Scrum facilitates face to face communication, and the daily standup is an opportunity to re-emphasize our commitments to each other and to the team. We say what we accomplished yesterday, what we are committing to get done today, and whether we are blocked in any way. <br />We also take time for follow-up discussions on any topic people want to bring up.<br />Everyone leaves the meeting knowing the exact status of the projects we’re working on.<br />We do this in 15 minutes or less per day. <br />Artifacts – a shared task board <br />Artifacts – a burndown chart for tracking progress <br />Let’s talk about some of the tactics we use successfully at IMVU <br />Standardize. <br />Shipping containers are all the same size. This is because they stack better, and are easier to manage efficiently. <br />But our teams were all doing something different…<br />We found that when our teams were doing things their own way, they didn’t work together that well. <br />Team workflows were too different; it was hard to swap team members and manage different process flows, and it was just harder for everyone to understand what we were working on, and why.<br />So we started with a standardized Scrum process, and now we mange the ongoing evolution of that process.<br />Then it was… <br /><ul><li> Team members understand processes for any team
    8. 8. Easy to swap team members
    9. 9. Easy to coordinate schedules
    10. 10. Easier to share best practices</li></ul>Changing and evolving your process, is, by the way, in conflict with most dogmatic or zealous approaches to project management. <br />So we avoid dogma. <br />For example, we decided that locking down the sprint backlog at the start of the sprint wasn’t working for us. Sometimes we need to react quickly to marketing needs or prioritize critical work. Unexpected things happen, and Scrum—or any other methodology--practiced dogmatically, doesn’t accommodate that very well.<br />Given that we’re committed to continuous improvement of our process, we avoid dogma at all costs. <br />So we call attention to changes in the sprint backlog daily in scrum and decide as team whether to accept the new work into the sprint.<br />Focused Meeting of Key Stakeholders<br />Solution for a successful planning meeting<br /><ul><li>Product Owner, QA, Tech Lead, Designer pre-plan together
    11. 11. Review draft design documents
    12. 12. Incorporate different viewpoints and approaches
    13. 13. Then revise to align documents</li></ul>Ground Rules for Planning Meetings<br />We want our teams to have a shared understanding of the sprint projects<br /><ul><li> Full team reviews detailed project planning
    14. 14. Planning takes 2-6 hours
    15. 15. Discussion, disagreement, new ideas, learning
    16. 16. Project scope changes
    17. 17. Detailed: we dive into the code and project designs</li></ul>Foster engagement during planning<br />No laptops or cell phones<br />No side conversations.<br />Share the keyboard: take turns driving the meeting<br />Take breaks, bring in food and refreshments<br />Something that deserves special mention is stakeholder agreement <br />We found that time spent to complete tasks was often different than planned, making sprint success difficult to predict<br />Solution: two engineers + technical lead must agree on task duration<br /><ul><li>Fosters engagement, discussion, and debate, and the result is a deeper understanding of task requirements
    18. 18. Accomplishes the same engagement as using story points and playing planning poker.
    19. 19. And the doors are locked and all the cold Coke Zero is held outside, until they agree. ;) </li></ul>We’ve found recently that a good target for team size is about 4 engineers per team.<br />Communication overhead increases quickly as you add people, and since scrum is all about lightweight, face-to-face communication, adding team members can quickly cause unforeseen problems.<br />We’ve found that about 4 engineers is the sweet spot for optimizing our ability to get things done efficiently and with high quality.<br />However, we learned that the hard way, but in 2 easy steps:<br />We created a great process… <br />2) We followed our process, and got into a comfortable routine. <br />We gradually increased our team size, and incorporated new practices to accommodate for subtle changes that were happening <br />Team made an optimization to reduce interruptions, based on a Best Practice from another team, allowing two team members to only fix broken tests (we use TDD).<br />Other team members were writing feature code more efficiently; fewer interruptions.<br />Oops.<br /><ul><li>Things got bad slowly
    20. 20. One group created problems that another group had to solve
    21. 21. No immediate feedback loop
    22. 22. We failed to understand the impact of an underlying infrastructure problem
    23. 23. Team too big—happened gradually</li></ul>Learn from your mistakes (and your successes)<br />Pay attention to what works and what doesn’t <br /><ul><li> Created best practice for team size: max 4 eng
    24. 24. Began using story points
    25. 25. Objective, high-level measure of velocity
    26. 26. Early signal of success/failure, even if team “seems” fine
    27. 27. Faster response time </li></ul>Over time you might develop some ALWAYS’S <br />What is an always’s you ask? These are things we do for every project, always. <br />Remind yourselves about these—write them on the whiteboard during your planning meeting!<br />(Planning Assumptions on the whiteboard)<br />We also write our planning assumptions on the whiteboard.<br />We make our assumptions public<br />This Reduce surprises, ensures engagement, helps catch errors. <br />Making these assumptions explicit means it’s harder to forget planned vacations, conferences, and other events that might affect planning. It also sets expectations for how much time each engineer will be contributing to achieving the team goals that sprint.<br />This is all part of our Planning Technology<br />This is one of our early scrum task boards. <br />A later version of our scrum task board:<br />Bigger <br />Painter’s tape<br />5 columns (Added QA + “New”) <br />“New” column: We realized we were in charge of our destiny, and that we wanted to accommodate new work coming into the sprint <br />In planning, we needed to refer to the old board AND make a new board.<br />Voila: the temporary task board<br />We spared no expense and found removable artists tape and black foam core… <br />And this board has some *sweet* features: <br /><ul><li>“New” column
    28. 28. Project Follow-up Lane
    29. 29. Physical size limits number of stories
    30. 30. Easy to add/remove tasks
    31. 31. Easy to meet, collaborate, plan work
    32. 32. Easy to move to meeting rooms
    33. 33. Easy to build
    34. 34. Hard to work with if you are remote!</li></ul>An online board is helpful with people working remotely from home or other locations <br />These tactics totally work for us<br />Except whenthey totally don’t<br />Context Matters: Some of our process works because of the particular context we have at a given time.<br />Context changes! Some of our greatest failures result from following our process. <br />You have to know when to deviate from your process. <br />You have to always remember that you are in control, you are driving. <br />A map can be a useful guide, but it is not a substitute for paying attention to what is going on. If you follow this map without thinking about it, you might run into problems. <br />Process is like a map.<br />Your process is not a replacement for being engaged and paying attention! <br />Plan your route! <br />Ensure that you are headed to the right destination. What your process or plan tells you is the right offramp, may not be. <br />Process is not a substitute for engagement.<br />Engage!<br />Be conscious!<br />Expect the unexpected.<br />Change your process in subtle ways that get people to engage…<br />Start using story points, for example…<br />Any change you make will create a problem for the team to solve, and require people to re-engage<br />So What Did We Learn? <br />Apply Build Measure Learn to your process<br /><ul><li>Fast iterations
    35. 35. Scrum basics
    36. 36. Standardize process
    37. 37. Avoid Dogma
    38. 38. Key Stakeholders
    39. 39. Ground Rules
    40. 40. Task Consensus
    41. 41. Team size
    42. 42. Always’s
    43. 43. Planning Technology
    44. 44. Thank you!</li></ul>James BirchlerEmail: jbirchler@imvu.comTwitter: @jamesbirchlerTweet this talk! #imvugdc<br />SLIDE COPY BELOW THIS POINT------------------------------------<br />Name one guaranteed winning tactic<br />
    45. 45. There isn’t one.<br />
    46. 46. You need a winning strategy.<br />
    47. 47. Today’s Specials<br />Pizza+Maps<br />
    48. 48.
    49. 49.
    50. 50.
    51. 51. +<br />
    52. 52. FAIL!<br />+<br />
    53. 53. Thanks to Eric Ries, http://startuplessonslearned.com<br />
    54. 54. Thanks to Eric Ries, http://startuplessonslearned.com<br />
    55. 55. Thanks to Eric Ries, http://startuplessonslearned.com<br />
    56. 56. Process Strategy & Revenue Timeline<br />($ millions)<br />Optimize & Scale<br />Explore & Build<br /> Photo by The Pizza Review http://flic.kr/p/4zYkdj<br />
    57. 57. Process Strategy & Revenue Timeline<br />($ millions)<br />Optimize & Scale<br />Explore & Build<br /> Photo by The Pizza Review http://flic.kr/p/4zYkdj<br />
    58. 58. Process Strategy & Revenue Timeline<br />($ millions)<br />Optimize & Scale<br />Explore & Build<br /> Photo by The Pizza Review http://flic.kr/p/4zYkdj<br />
    59. 59. Photo by CarbonNYC http://flic.kr/p/KTPYW<br />
    60. 60. Prod Dev Strategy & Revenue Timeline<br />($ millions)<br />
    61. 61. Process Strategy & Revenue Timeline<br />($ millions)<br />Optimize & Scale<br />Explore & Build<br />Photo by http://www.canpages.ca/blog/?p=508<br />
    62. 62. Process Strategy & Revenue Timeline<br />($ millions)<br />Optimize & Scale<br />Explore & Build<br />Photo by http://www.canpages.ca/blog/?p=508<br />
    63. 63. Photo by Robert Otani<br />
    64. 64. Photo by Robert Otani<br />
    65. 65.
    66. 66.
    67. 67.
    68. 68.
    69. 69.
    70. 70.
    71. 71. Technical Debt<br /> #!@$%<br />
    72. 72. Outdated Process<br /> #!@$%<br />
    73. 73. Catch-22?<br />#!@$%<br />
    74. 74. Floppy Drive Photo by Accretion Disk http://flic.kr/p/MaphG<br />
    75. 75.
    76. 76.
    77. 77.
    78. 78. Prod Dev Strategy & Revenue Timeline<br />($ millions)<br />Optimize & Scale<br />Explore & Build<br />Adapt & Learn<br />
    79. 79. Thanks to Eric Ries, http://startuplessonslearned.com<br />
    80. 80. Strategy: Apply <br />Lean Startup theory to your process<br />
    81. 81.
    82. 82.
    83. 83. “The most productive teams ever.”<br />
    84. 84. Prod Dev Strategy & Revenue Timeline<br />($ millions)<br />Optimize & Scale<br />Explore & Build<br />Adapt & Learn<br />
    85. 85. Prod Dev Strategy & Revenue Timeline<br />($ millions)<br />Optimize & Scale<br />Explore & Build<br />Adapt & Learn<br />
    86. 86. ($ millions)<br />How?<br />
    87. 87. 3-Week Sprint = Fast Learning Cycles<br />Current Sprint<br />Progress<br />
    88. 88.
    89. 89.
    90. 90.
    91. 91. Cool Chart Porn<br />
    92. 92. Tactics<br />Land<br />Photo by BoogaFrito http://flic.kr/p/8njLQ1<br />
    93. 93. Photo by photohome_uk http://flic.kr/p/3h5aAH<br />
    94. 94. Photo by Bayhaus http://flic.kr/p/7CNcLm<br />
    95. 95. Dogma<br />
    96. 96. “New” task column<br />
    97. 97. Product OwnerTechnical LeadQuality EngineerDesigner<br />
    98. 98.
    99. 99. Time estimates by 3 engineers<br />
    100. 100. Time estimates by 3 engineers<br />
    101. 101. Photo by anyjazz65 http://flic.kr/p/54F4yx <br />
    102. 102. 1. Create process.<br />
    103. 103. 2. Follow process.<br />
    104. 104. Success!<br />We did it! <br />Photo by foundphotoslj http://flic.kr/p/GApHn<br />
    105. 105. <ul><li>Project-level postmortems
    106. 106. Sprint-level retrospectives
    107. 107. 5 Whys root cause analysis</li></ul>Photo by AdamL212 http://flic.kr/p/KnNa7<br />
    108. 108.
    109. 109. Assumptions<br />Public<br />
    110. 110.
    111. 111.
    112. 112. Task Board v2: Bigger, “New” Column<br />
    113. 113. Task Board v2.5: Temp Board<br />
    114. 114. “New” tasks column<br />“Follow-up” tasks lane<br />
    115. 115.
    116. 116. These tactics totally work for us.<br />Awesome. <br />
    117. 117. Except whenthey totally don’t.<br />Less awesome.<br />Photo by Justin Marty http://bit.ly/bLcko7<br />
    118. 118.
    119. 119. Photo by alancleaver2000 http://flic.kr/p/7xow5z<br />
    120. 120. <ul><li> Apply to your process
    121. 121. Tactics
    122. 122. Fast iterations
    123. 123. Scrum basics
    124. 124. Standardize process
    125. 125. Avoid Dogma
    126. 126. Key Stakeholders
    127. 127. Ground Rules
    128. 128. Task Consensus
    129. 129. Team size
    130. 130. Always’s
    131. 131. Planning Technology</li></ul>Photo by Brilliant Michael http://flic.kr/p/7mFH5o<br />
    132. 132. Q & A <br />Thank you!<br />James BirchlerEmail: jbirchler@imvu.comTwitter: @jamesbirchlerTweet this talk! #imvugdc<br />

    ×