Modern agile is heavily influenced by Lean Software Development, as described by Mary and Tom Poppendieck in Implementing Lean Software Development: From Concept to Cash . What are your release bottlenecks and what will help you flow value to users faster? In Prioritizing Happiness , I called this Hypothesis to Happiness: what hypotheses must you test to quickly produce happy users? Doing that requires planning and delivery optimized for safe, frequent releases to production.

Paul O'Neill, former CEO of Alcoa, once said, "Priorities change while our focus on safety never changes. Safety is a prerequisite, not a priority." People don't function well when they live in fear. If someone is fired or penalized for a mistake, everyone becomes afraid of a similar fate and productivity plummets. When safety is present, users trust your software, developers are unafraid to change code and people feel safe to fail and learn from mistakes. In Managing the Risks of Organizational Accidents , James Reason points out that most mistakes begin life as latent conditions, problems that existed in the environment for years and happened to be triggered one day by some unfortunate soul. Making safety a prerequisite enables other modern agile disciplines, like Experiment & Learn Rapidly and Deliver Value Continuously. Developing great software requires protecting the people who use it, make it, fund it, buy and sell it. I call this Anzeneering and it underlies everything we do in modern agile.

Kathy Sierra nailed it in her book, Badass: Making Users Awesome . You must aim to make users awesome at whatever they're using your software to do. Too many companies lose focus on users as they attempt to produce awesome technology or market themselves as a great company. Steve Jobs once explained how Apple approaches product development by first asking "What incredible benefits can we give to the customer? Where can we take the customer?" rather than looking at what amazing technology we have and can market. Focusing on users and their needs is the idea behind Jeff Patton's User Story Mapping: Discover the Whole Story, Build the Right Product .

Modern Agile Principles/Practices

Many of the principles/practices in each of the four circles overlap with other circles. In the descriptions below, I've included labels to make those overlaps clear. Labels in bold indicate the primary group to which an item belongs:

Charter Your Work Make Users Awesome Make Safety a Prerequisite If you want to make awesome users you need to define what that means. Agile chartering is a lightweight practice for product communities to discover and align around a clear vision, mission and testable outcomes. It's not something you do once at the beginning of a project: chartering is an ongoing endeavor (hence the "ing" in chartering). Good chartering is like a guardrail: it keeps you from going off the road. Ainsley Nies and Diana Larsen, two experts in chartering, describe this important practice in their book, Liftoff: Launching Agile Teams & Projects.

Leverage Lean Startup Experiment & Learn Rapidly Make Users Awesome Make Safety a Prerequisite Whether you develop software for a large organization, small startup or something in-between, you would do well to tap into the wisdom of Eric Ries' classic, The Lean Startup. In our quest to make users awesome, Eric helps us understand that most of us are "operating under conditions of uncertainty" and clarifies how unsafe it is to guess what users need. He suggests a variety of useful ways to discover what to build, including fast, frugal experimentation and rapidly validating/invalidating hypotheses before investing in finely crafted code. If you aren't learning whether users are actually using, benefiting from and being badass with your software, you likely need to redefine your Definition of Done. And if you are struggling to scale lean in your enterprise, you'd do well to study Lean Enterprise: How High Performance Organizations Innovate at Scale by Jez Humble, Joanne Molesky and Barry O'Reilly.

Apply Lean UX Experiment & Learn Rapidly Make Users Awesome Closely related to Lean Startup is Lean UX, a fast, inexpensive, analytics-driven approach to discover and produce outstanding usability. I learned the Feature Fake technique (one of many Lean UX techniques) from Laura Klein, a leading figure in the Lean UX community. You can learn more about Lean UX from Jeff Gothelf and Josh Seiden in Lean UX: Applying Lean Principles to Improve User Experience and Laura Klein's UX for Lean Startups: Faster, Smarter User Experience Research and Design.

Collaborate & Integrate Frequently Experiment & Learn Rapidly Make Safety a Prerequisite Deliver Value Continuously Poor collaboration and integration inside a team or across teams exposes organizations to hazards. This is the root cause of many problems in software development. Solo work tends to produce knowledge silos (when only one person knows how something works), greater defects, weaker problem solving, more distractions and less discipline (especially around writing good tests and improving design via refactoring). Pairing is the practice of having two people complete work together and swap pairs regularly. Mobbing is a community approach to development, in which three or more people work together, regularly swapping who "drives" the keyboard/mouse. Both pairing and mobbing increase the rate of learning, accelerate the flow of valuable results, reduce hazardous dependencies on key skills/knowledge, enable easier changes to technology and bring out the best in people. Some shops are also quite effective at enabling deep solo work, followed quickly by collaboration on code review and integration into a master code base.

Make it Safe to Fail Make Safety a Prerequisite Experiment & Learn Rapidly If you have a culture of fear, none of your fancy practices or processes will help you. The best companies foster a culture in which people feel safe to experiment, fail, disagree and be themselves. Dave Snowden talks about using safe-fail probes, small-scale experiments that help you learn valuable lessons in the context of a complex system. Companies that make it safe to fail are learning organizations. Etsy is a shining example. One of their newest hires brought down their website by accidentally deleting a critical CSS file. What did they do? They gave the engineer their three-armed sweater award for discovering a significant flaw and fixed the design to be more resilient.

Test & Refactor Make Safety a Prerequisite Deliver Value Continuously Testing and design are essential to agility. Modern agilists perform exploratory testing, automated testing, test-driven development (which is primarily a design activity, and secondarily a testing activity), and some manual testing. One quantitative study of modern agile communities trained and coached in testing and refactoring by Industrial Logic found that defects dropped by over 80%. By producing dependable, high-speed, automated checks of software behavior, programmers have a safety net that allows them to work faster, with less fear of changing code or producing defects. Refactoring (improving the design of existing code without changing behavior) is a critical practice to keeping design complexity at bay and making code simple and understandable (and therefore easier to change). Refactoring is revision, which in latin means to re-see (re-videre). We revise things as we learn more, discover flaws in our earlier work and endeavor to improve the design/readability/simplicity of our code. Both testing and refactoring are essential to a team's speed and are therefore a critical part of modern agile.

Respect & Appreciate People Make Safety a Prerequisite Sincere respect (regardless of role, seniority, education, race or gender) and appreciation are core to establishing a culture of safety. Anzeneers respect people by protecting their time, money, information, reputation, relationships and health. When the collaboration app, Slack, sends me an email to say they've refunded my account some amount because a user didn't access their service all month, I feel respected and cared for. Paul O'Neill, former CEO of Alcoa and the Treasure Secretary of the U.S.A., said that for organizations to achieve habitual excellence, they must have a culture in which people are respected and appreciated every day by everyone. At Industrial Logic, we use DueProps to regularly appreciate people.

Conduct Blameless Retrospectives Make Safety a Prerequisite Experiment & Learn Rapidly Seth Godin once said, "People aren't afraid of failure, they're afraid of blame." In Norm Kerth's 2001 classic book, Project Retrospectives: A Handbook for Team Reviews, he observed that "One of the most obvious fears people have when first trying a retrospective is that the ritual will become a negative gripe session, interspersed with blame and counter blame." So Norm defined his now-famous Retrospective Prime Directive, which is customarily read before a retrospective: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. This directive sets up retrospectives to be safe places focused on learning. Etsy's John Allspaw writes about this in Blameless Postmortems and a Just Culture. And Esther Derby and Diana Larsen have an excellent book called Agile Retrospectives: Making Good Teams Great.

Focus on Flow Deliver Value Continuously Modern agile prefers continuous flow over working in time boxes (e.g. sprints or iterations). Kanban enables continuous flow. Using a kanban board, teams visualize their work on a board, pull important work across columns, limit work in process, support classes of service (e.g. urgent or normal work), visualize and remove bottlenecks and flow value to users in production. You don't spend time trying to predict how much work you can do during a time box, accounting for the exact number of storypoints or trying to look good by publishing an attractive burn-down or burn-up chart. This is streamlined agile planning. David J Anderson describes it beautifully in his pivotal book, Kanban: Successful Evolutionary Change for Your Technology Business.

Deploy & Release Continuously Deliver Value Continuously Make Safety a Prerequisite Kent Beck once pointed me to a stunning video by Timothy Fitz called "Doing The Impossible 50 Times A Day." (Alas, a hapless ISP lost Timothy's awesome video, but he wrote a blog about it). Timothy described how IMVU (the birthplace of Lean Startup) took the practice of Continuous Integration (CI) far further than early agilists had conceived by safely deploying to production many times per day. The CI dial had been turned to 11. Continuous Deployment powers early, fast experimentation in production (e.g. A/B tests) and allows you to rapidly and safely deliver what users most need as fast as possible. It's one of my favorite lean-influenced practices because it dramatically reduces the "Concept to Cash" cycle. Timothy Fitz authored a CD eLearning course with Industrial Logic and is presently writing a book on this modern agile practice. Jez Humble and David Farley are deep experts in the practice and authors of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.

Form Product Communities Deliver Value Continuously Make Safety a Prerequisite Without the right people, you won't be able to create software that makes users awesome. The right people make up your product community. In the words of David Schmaltz, a product community is "a population of people that effect a product or can be affected by a product." David observes that such a community is ALWAYS bigger than you think and that the primary issue facing most product efforts is the "lack of awareness of its own community-ness." A product community isn't separated into front end, back end, middleware and UX teams, each with it's own backlog. A product community is full stack, ready to evolve a primitive solution into a sophisticated offering that makes users awesome and helps the organization succeed. Forming a product community helps people gain awareness of who does what and how they are vital to helping achieve key outcomes. Defining and refining your product community often happens during Chartering.