Agile Agile: Adapting Practices to Support Explosive Growth by Ben Foster
•
1 like•716 views
How should the Agile process evolve as a startup matures? How can Agile succeed when clients expect hard feature/date commitments? How can Agile concepts be applied outside of the product development process? This talk will answer all these questions and more, and offer real-life examples through a case study of one of the DC region's most successful startup stories, Opower. Utilizing Agile in unique ways has contributed heavily to the company's explosive growth. The ideas tried and lessons learned are broadly applicable, as Opower is a "big data" SaaS company spanning both enterprise and consumer worlds: it sells its product to the highly regulated and notoriously slow-moving utility industry, but delivers value by using cutting edge behavioral science to deliver actionable insights and targeted communications directly to consumers, ultimately helping them save on their energy bills.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (8)
Similar to Agile Agile: Adapting Practices to Support Explosive Growth by Ben Foster
Similar to Agile Agile: Adapting Practices to Support Explosive Growth by Ben Foster (20)
More from LitheSpeed
More from LitheSpeed (20)
Recently uploaded
Recently uploaded (20)
Agile Agile: Adapting Practices to Support Explosive Growth by Ben Foster
- 1. Agile Agile Adapting Practices to Support Explosive Growth Ben Foster VP Product Management, Opower Copyright Ben Foster 2013 @pmranter
- 2. Who is this guy up here?
- 3. You can apply Agile practices to anything… even Agile itself.
- 4. What I want you to take away Creating a prioritized backlog is hard work The ways you use Agile should change as the company grows Agile is for more than just product development Tangible solutions for similar problems in your company
- 5. An engineering view of Agile Magic!
- 6. Backlog management is really, really complicated.
- 8. How prioritization (actually) works Sales Marketing Engineering Operations Regulators Customer service Product managers Executives Residential customers Efficiency directors Small business customers CSRs IT staff Investors Competitors Partners
- 9. Don’t do Agile for Agile’s sake. Use it to solve your current business problems.
- 10. A company growth journey Stage Pro Con 1 Just starting Nothing to support Relying on blind faith 2 Small – few customers Real market data Need to focus 3 Medium – whale hunting Potentially significant scale Whales want your soul 4 Big – rapid expansion Massive opportunity Organizational scaling 5 Clear industry leader Thought leader Major complexity
- 11. Stage 1: no revenue 1 Just starting Nothing to support Relying on blind faith
- 12. Stage 2: small – few customers 2 Small – few customers Real market data Need to focus
- 13. Stage 2: small – few customers 2 Small – few customers Real market data Need to focus
- 14. Stage 3: medium – whale hunting 3 Medium – whale hunting Potentially significant scale Whales want your soul
- 15. Stage 3: medium – whale hunting 3 Medium – whale hunting Potentially significant scale Clients want your soul
- 16. Stage 4: big – rapid expansion 4 Big – rapid expansion Massive opportunity Organizational scaling
- 17. Stage 4: big – rapid expansion 4 Big – rapid expansion Massive opportunity Organizational scaling
- 18. Stage 4: big – rapid expansion 4 Big – rapid expansion Massive opportunity Organizational scaling
- 19. Stage 4: big – rapid expansion 5 Clear industry leader Thought leader Major complexity
- 20. Stage 5: clear industry leader 4 Big – rapid expansion Massive opportunity Organizational scaling
- 21. Stage 5: clear industry leader 5 Clear industry leader Thought leader Major complexity
- 22. Stage 5: clear industry leader 5 Clear industry leader Thought leader Major complexity
- 23. Stage 5: clear industry leader 5 Clear industry leader Thought leader Major complexity
- 24. Stage 5: clear industry leader 5 Clear industry leader Thought leader Major complexity
- 25. Stage 5: clear industry leader 4 Big – rapid expansion Massive opportunity Organizational scaling
- 26. Stage 1 – no revenue 1 Just starting Nothing to support Relying on blind faith
- 27. Stage 1 – no revenue 1 Just starting Nothing to support Relying on blind faith Is rapid iteration even appropriate at this stage?
- 28. Agile isn’t just for product development
- 29. Daily Stand-ups for management?
- 31. Iterations for operations? Start PSE Release Build Build QA OpsQA Retrospective QA QA Retrospective Week 1 Engineering Week 2 Week 3 Regression UAT UAT Build Build Regression
- 32. Well, maybe not Start PSE Release Build Build QA OpsQA Retrospective QA QA Retrospective Week 1 Engineering Week 2 Week 3 Regression UAT UAT Build Build Regression
- 33. Conclusions Backlog prioritization and Agile practices should vary based on your type of company and your maturity level Agile has application outside of product development Specific recommendations: » Use roadmap color-coding to explain “why”. » Knowledge is it’s own product. Treat it that way. » Push decisions down with core teams.
Editor's Notes
- Thanks for attending this talk.It’s called Agile Agile – Adapting Practices to Support Explosive Growth.How many of you would say you work in a start-up?How many of you are experiencing fast growth or expect to soon?
- First just a little about me. I’m Ben Foster.I’m a Product guy through and through. I’ve been leading Product Management and UX for about 15 years now.I worked most of my career in the Bay Area, but I’ve been in Arlington for the past 4 years or so.The common theme of my career has been putting together lots of data, generating useful insights, and then using those to motivate behavior.At eBay, I applied this to merchandising: cross-sell and up-sell.At Adchemy, I applied this to digital marketing: display and SEM ads.At Opower, I’m doing it to save the planet: getting people to be more energy efficient in their homes.All of these have been pretty big success stories, but that’s not to say I haven’t also had my failures.Has anybody heard of Webvan? One of the biggest dot-com disasters of all time. Went through $300M in the bank and $1B in market cap in less than a year.So, we’ll just pretend that didn’t happen.
- You’re probably wondering what I mean with Agile Agile.This is basically it. Agile isn’t a one-size-fits-all process.It’s a method for solving business problems. And those business problems will change as your company matures.
- Here’s what I’m hoping to cover in this talk.First we need to talk about backlog creation. Then…I’d like you to walk away recognizing thatAgile should be adapted and customized for your needs.You can – and should – apply Agile to more than just development.There are some helpful tricks we’ve used at Opower that you can apply at your company, too.
- Every seen this?You’ve got this sprint backlog that you pull out of the product backlog, and run daily scrums and iterations to create shippable product.I love this! How perfect!But hold on, where did that product backlog come from? It’s just magic!
- It’s not really covered in the literature because:Agile is really intended to streamline developers.Backlog creation/management is really complicated.
- I’m going to reference Opower examples throughout, so it would help to get a quick background.As I go through, think about how many similarities there are between our business and yours.<walk through diagram>Easy, right?
- So, creating the backlog is just about prioritizing customer needs…Well, user needs, too.Well, except where users don’t know what they need. Or even what they’ll actually respond to.And then there are internal users.And buyer personas. And user personas.And then there are those pesky competitors. But some of them could be partners if we just had APIs.Ugh!So, how do we balance all this and turn it into a single prioritized backlog?
- Agile will fall apart if your prioritization process isn’t right. Smart prioritization, is critical.Before you adopt Agile, clarify why you’re doing so. What are the key business problems you’re trying to solve?Is it delivering on time? Why is that the priority? Is it getting user feedback as you go? Which types of users?
- These business problems change dramatically as your company grows, and it can feel like you’re in a tornado when you’re experiencing hyper-growth.So, plan for it. Take a step back and consider what phases of maturity your company will go through based on your type of business.Opower sells a SaaS product to an industry that is used to custom solutions. There are only a few hundred clients worldwide, so each one matters. Some are incredibly strategic. Our end users never ask for our product, so acquisition and retention are non-issues. What does this look like for you?While it may be different from Opower’s, I can assure you many similar themes will emerge.Let’s go through these one stage at a time.
- This is the no-revenue stage. You are still building your minimum viable product.I think this was actually the most complicated situation for Opower and so I’m going to skip it for now. We’ll come back to it.
- This picture was taken in early 2010. You can tell because that’s me and there was far less sign of me balding. When I joined Opower, we had a lot of problems.Problem 1: Sales didn’t even know we had a roadmap!Solution: Better communication with right level of assurance using velcro and mounted cards.Problem 2: Sales was unknowingly taking over the roadmap with customizations.Solution: We used color-coding to show senior management the state of the union.
- Problem 3: Yellow (and occasional green) cards kept pushing blue ones out.Solution: We created an internal marketplace using tokens. Senior management made a top-down call on appropriate % of dev for customizations, then we forced sales to force-rank their own requests.
- That worked really well… until it didn’t. And that was clearly the point that we moved to stage 3.Problem 4: We had a whale opportunity. Winning or losing would define the company for the next few years. But reeling it in required some very tough tradeoffs.Solution: We had to commit to feature-date pairs and flex on how much of the team would be required – and how much of our roadmap we’d push out.
- Problem 5: The token process broke down. The right thing was to spend far more tokens than Sales had.Solution: Meet the client need, but have a plan to take our roadmap back, which required building features the right way.(This was covered in a HBS case study I can share with you individually if you’re interested. Just talk to me afterward.)
- So, that consumed 2/3 of our roadmap for the next 1.5 years. It sucked! But, it was great – we parlayed that win to go on a tear and capture enormous market share. So, now we had a rapidly-expanding business.Problem 6: With rapid scaling came rapid internal growth. New positions. New people. New people training new people. Multiple office.Solution: We had to migrate our agile processes to all-digital formats. JIRA and Confluence. No more paper cards. All the views were there.Problem 7: Managing everything digitally required a lot of overhead, ownership of tools, and centralizing the process.Solution: We built a team of experts who are responsible for ensuring smooth product development process (even outside of R&D) and owning the tools and process.
- Problem 8: We had to streamline our processes (client deployment, customer support, contracting, etc.). And no one was on the same page.Solution: Huge investment in documentation and knowledge sharing – and treating it as a PRODUCT itself. With a team dedicated to it. Aware of their own velocity. Producing shippable knowledge increments.
- Here’s an example of one of those knowledge sharing products – the “prodcast” newsletter which pushed the right information out.
- Here’s another internal product – “How Stuff Works” videos designed to educate about what product capabilities we now have and where the product is headed.
- Problem 9: So, we still needed to take back our product roadmap, but we can’t change our clients overnight. A SaaS (or non-customized) solution is still novel to them.Solution: Create the right long-term technology solution that solves the problem once and for all. And don’t down-prioritize it.Don’t be afraid of talking about technology to non-technical folks. They need to be able to get it at least at a basic level.You can do this because you’re now the leader and clients prefer to do business with you.<add picture>
- Problem 10: The management team can’t approve every major decision, but they need to know their teams’ interests are being considered.I’ve seen all kinds of solutions for this: product council, big review meetings, etc.Solution: Core teams with delegates from each department who can collectively make decisions. Product manager at the helm.<change image>
- Problem 11: Syncing between scrum teams gets really laborious.Solution: Science fair, posters on the wall, Q&A. 2 days down to 2 hours.
- And technology can pave the way. We use Lifesize systems for communication across offices.
- Problem 12: Need to roll up a level: we’re telling a bigger story now. User stories and even epics aren’t enough.“As a utility, I can make my customers happy even though they hate me.”Solution: More up-front work for product directors to create these “sagas” and get buy-in.Delivery of working ideas is as important as delivery of working software
- Problem: <change picture to show Structure on top of JIRA>
- If we had used Agile, we never would have built our first productCan’t respond to feedback when all the feedback is that there is no interest
- Problem: Senior management meetings were turning into PowerPoint presentations and was moving too slow. Escalations weren’t being addressed quickly enough.Solution: Daily stand-up for senior management!
- Problem: We could grow fast enough, but couldn’t tell where to focusSolution: Created Candidate “Catapult” based on Jobvite APIs to show us where the bottlenecks were broken down by job, by source, by hiring manager, etc.
- Problem: Operations experienced similar problems to product development: too much tech/process debt, disjoint work + QA, lack of management clarity of velocity, slow information exchange about blockers and dependenciesSolution: Created a scrum team and an aligned iteration calendar, instituted agile practices, managed burndowns, etc., and then aligned with engineering
- That helped a lot, but it ultimately failed due to:- Too many external dependencies (on clients)- Too many one-off issues that couldn’t be predicted in advance (priorities changing mid-iteration)
- Well, that’s just about it. Thanks for taking the time today.I really hope this was valuable for you. If you’d like to follow up with me on anything, don’t hesitate to reach out across any of these channels.I’ve been spending more and more time doing “volunteer advising” for startups, particularly those with a mission to make the world a better place.Alright, thanks everyone!