Top 20 FlowCon Slides: Continuous Delivery & Lean Product Design

Breadcrumb

FlowCon is a new conference aimed at supporting organizations that want to create more innovation through continuous delivery and lean product development. The idea is to translate great ideas into things people can use as quickly as possible, and become more responsive to business needs, through agile practices and DevOps culture.

Puppet Labs attended this inaugural conference as a sponsor. We've collected 20 presentations highlighting top ideas discussed at the conference, especially for those creating web applications.

The biggest pain point driving companies to adopt agile practices and continuous delivery is their need to deliver innovation to users as quickly and efficiently as they can. For Netflix, doing a great job of recommending the next movie you should watch is more important than consistency of the streaming experience, or even price point. Keeping users engaged and happy by helping them find movies they'll love trumps all other priorities. Netflix can keep a competitive advantage by continuously delivering features to power users while minimizing changes for the laggards who want everything to stay the same.

.@adrianco: "In short, everyone needs to get on top of Agile, continuous delivery, DevOps in order to compete." #flowcon

2. Businesses Need To Be More Agile

More companies are adopting agile practices to respond quickly to business conditions and needs. Changing from the waterfall method of software development to agile practices can be a slow process over many years, because there's no template that works out of the box. Agile is really a philosophy, and has to be adapted to fit each company's workflow and culture.

Even if you can't do continuous deployment you should be doing continuous improvement. #flowconsf

3. Iterate Until Awesome

The lean startup ethos is "build, measure, learn." It's a very iterative process. The first iteration may completely suck, but it may provide some viable functionality with minimal effort. The idea is to persevere through this process until you end up with something that's awesome.

Continual experimentation is critical. Launch is only the first step, must continue to iterate and engineer success #flowconsf

4. Less Waterfall, More Innovation

It's interesting to see how developers spend their time working within the waterfall model of development compared to working within a more agile framework. There's a lot less upfront planning, and a lot more time available to innovate when working the agile way. Some developers are getting more authority and freedom to become product owners and even root access to servers, but with that power comes great responsibility, such as rotating pager duty.

In context of dev responsibility on owning releases, “you run what you wrote, you get root access AND you get PagerDuty.” @adrianco#flowcon

5. The Before & After of Continuous Delivery

Jez Humble said the purpose of continuous delivery is to make software release boring and uneventful, rather than a huge event that is enormously stressful for everyone involved. It's about creating a sustainable pace that in the end is more responsive to business needs, but more than anything else improves the quality of life for everyone: developers, IT operations people, managers, and all stakeholders.

“No one ever said I want to go away from stable, boring, small releases & go back to weekend waterfall disasters.” @jezhumble#flowconsf

6. Netflix's Continuous Delivery Feedback Loop

Adrian Cockcroft's presentation demonstrated how the OODA (observe, orient, decide, act) feedback loop has evolved over time. He mapped each component to Netflix's webscale cloud architecture. Observing is about keeping tabs on the competition and making sure Netflix stays one step of everyone else through innovation. The company is able to orient to a baseline of success through the process of collecting and analyzing a ton of big-data metrics. The power to make decisions was moved down to the level of developer implementors through a culture of "just do it." And finally, Netflix is able to execute via a continuous deployment infrastructure that runs in the cloud (with most of their code open sourced on GitHub.)

“Cloud native: construct a highly agile and highly available service from ephemeral and _assumed broken_ components.“ @adrianco#flowcon

7. Relative Latency of Different Feedback Loops

Fast and informative feedback loops are essential to the process of lean product development and continuous deployment. Each layer of feedback has increased latency: Automated unit tests are the fastest, and customer opinion of the delivered product is the slowest. These feedback loops are vital because you need to see quickly if your implementation matches your intentions, and whether you are meeting an actual need.

.@testobsessed "If the cost of automating test is too high, then what you have isn't a test prob but a software design failure." #flowconsf

8. The Tricky Parts of Continuous Delivery

Web applications have many moving parts, and continuous delivery is sometimes easier said than done. Some of the more painful aspects are around database migrations and the ability to quickly revert a deployment if it introduces a bug or a decreased level of performance.

9. A Bad Canary Example from Netflix

Being able to quantify the state of your system across a number of metrics is a key component for pushing out and evaluating a canary test deployment. Above is an example of a Netflix canary with three aspects that go beyond the company's standard deviation. This specific experiment would be rejected, reverted, and then the team would conduct an analysis of what may have gone wrong, with some potential refactoring.

Netflix first deploys canary tests to Europe in the middle of the night during U.S. working hours. Then the team progressively deploys the canary through different regions: Europe, U.S. East, and U.S. West, taking a full day to run it through all regions. Metrics are evaluated only after at least a full day of full load, because sometimes a feature will work at small scale, but fail under peak load.

10. Things that Should Be in Configuration Management

Configuration management is the baseline for ensuring that your development, staging and production environments are as identical as possible. The less deviation in these environments, the more confidence that you can have that an application that passes tests in the dev and staging environments is ready to deploy into production. It's also a good idea to decouple the environment-specific variables and information listed above from the application code within your configuration management tool of choice.

11. Six Principles of Kanban

Kanban is a popular agile process that helps your team visualize its workflow, and optimize efficiency by not doing too many tasks at once. It originated with the Toyota Production System as a way to facilitate swarm behavior and remove bottlenecks on a factory production line. Oddly enough, Kanban principles that work so well in manufacturing can also be applied to building software. One example is that the Kanban board radiates information to everyone on the team, and encourages collaboration.

12. Product Development Lifecycle

Jeff Patton says it shouldn't be your goal to just build and ship more stuff. Instead, you should minimize your output while maximizing your impact and outcomes. As a product owner, you should not just look at data. You need to go to where the users are, because you can't get empathy from looking at numbers. Jeff showed some examples of teams that left delivered features on their Kanban board for months until they were able to gather feedback and data from users.

"Requirements is a word that means 'shut up'" and code this instead of asking questions #flowcon

13. Lean Product Design Principles

Working on a team of six people is a lot different from working on a team of 60. Joe McLean and Natalie Hollier walked through a case study of a company that went through different iterations of lean product design as it grew to 10 times its size. While small teams can start easily and move fast with a lot of uncertainty, larger teams feel more pressure to plan; it's harder to implement change when there are more decision makers. One way the company managed to scale was to embed designers with goal-oriented teams, and to use a combination of lean process, lean tools and lean mindset.

14. Five Principles for Design Thinking

Design thinking is not about creating buttons, colors and layout. It's about weaving the principles of design into the DNA of your company, and realizing everyone can have an impact on finding ways to add more customer value. It's about cultivating empathy for the pain the user is experiencing, generating creative ideas, and analyzing how well those solutions work.

Courage: "If you're in small company, I urge you to try to make Design Culture; In large company, still try. :)" #flowconsf

15. A Recommended Lean UX Design Cadence

Lean user experience is all about doing quick experiments with teams that have diverse roles — for example, developer, designer and product owner. The conflicting perspectives of these different people help challenge a groupthink mentality and generate creative solutions. However long the sprint duration, the goal is to take the path that prioritizes completing a whole deliverable. Check out Courtney Hemphill's slides for more info on some of the user story process and tools that Carbon Five uses in its lean UX workflow.

16. Create a Virtuous Cycle of Hiring

All the tools, techniques and continuous delivery processes in the world won't amount to much if the company is unwilling to change its culture and adopt the new ways. A key element for building a high-performing team that can sustain a high velocity cadence is hiring the right people, and cultivating a culture that's dedicated to continuous improvement. Randy Shoup shares characteristics he's found are vital to creating a Virtuous Cycle of Velocity.

17. Mind the Tech Diversity Gap

Diversity in the tech community is a hot topic, as there are few women and minority-group members in tech, relative to the general population. This is a problem, because the more diversity and differing perspectives on a team, the more creative the solutions that can be generated. FlowCon organizers paid particular attention to including some new voices that haven't been heard before, and Ashe Dryden packed quite a lot of info into her Programming Diversity talk.

Only 3% of OSS contributors are women; so, "We only look at Github profiles when hiring" is a huge primary selection bias. #flowconsf

18. Top 10 Steps for Refactoring Code

When features are rushed to delivery, there's no time to do it right, so a lot of technical debt accumulates. The way around this is to build time for refactoring into the process of development. Ideally, you perform a series of tests against your code so you can aggressively refactor code while ensuring that functionality is still working. Katrina Owen managed to present 301 slides on refactoring code in 30 minutes, and I took the liberty of aggregating the top 10 areas to start refactoring.

"The thing to do with big ugly code is to break it down into small ugly code." @kytrinyx#flowconsf

19. Auditing Trends Are Slowly Catching Up

Advances in the auditing world are trailing behind the maturity of agile software development practices. This means that there is sometimes tension between compliance with various standards and being able to make progress efficiently. James DeLuccia from Ernst & Young LLP offered some tips for how DevOps-friendly organizations can navigate these auditing realms.

20. Most Decisions Are Not Made from a Rational Place

In her book, Fearless Change, Linda Rising lays out 48 myths for working with other human beings. One interesting insight Rising shared is that most people don't make decisions with the rational mind, and that a lot more emotional, instinctual and subconscious decisions are made than people like to admit. So when you're trying to make change in your organization, feeding your colleagues homemade cookies can be a lot more effective than logical arguments or mustering a lot of facts.

"You don't have to have a good idea. You just have to have good cookies. Quality of cookies beats quality of idea." @RisingLinda#flowconsf