Have you ever seen someone using an older laptop and just felt bad for them?
That's how I feel when I see most people practicing agile these days.
We've advanced so far beyond where agile was in the mid 1990s, yet so many teams practice agile like it's 1999!
Meanwhile, agile/lean pioneers and practitioners have identified common failures, experimented with newer approaches and found better ways of working.
Today's agile resembles a modern laptop: lighter, safer, simpler, sturdier, more powerful and pleasant to use.
Since it looks and feels quite different from traditional agile, is modern agile for advanced practitioners only?
No, no more than a modern laptop is for advanced computer users.
Reinventing Agile
A few years back, I remember feeling a sense of loss when I realized that my new Apple laptop no longer had a built-in DVD/CD drive.
And as the months passed, I found that I didn't miss it.
You may find the same thing with modern agile: discovering you don't need something you once thought was so valuable.
I once thought that story point estimates, calculating velocity and fixed-length time boxes (A.K.A. sprints or iterations) were essential, yet now I use none of them in my agile practice.
Modern agile simplifies and streamlines traditional agile processes while making them sturdier.
For example, Continuous Deployment requires a dependable release pipeline by which you can rapidly and safely deliver value to users.
Kanban helps people focus on flowing value to users rather than getting bogged down in outdated, traditional planning rituals.
Modern agile holds up to wear and tear better than traditional agile processes because it strikes a better balance between business and technical agility.
The result brings us closer to the dictionary definition of agile: moving with quick, easy grace.
What's In Modern Agile?
Every veteran agile practitioner will have a different idea of what is in or out of modern agile. I'm sharing my latest thinking on the subject and it will surely change as I learn more. Please add your 2 cents to the feedback section of this blog.
Modern agile consists of four, overlapping disciplines that include a dozen overlapping principles/practices:
Here's a description of the four disciplines:
Make Users Awesome
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.
Make Safety a Prerequisite
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.
Experiment & Learn Rapidly
The most effective software groups are committed to experimenting and learning. At Intuit, product development decisions used to be based on who had the best looking slide presentation or loudest argument. Now those decisions are based on quantitative data harvested from tests in production. At AirBnB, engineers monitor core business metrics after a deployment to rapidly learn whether an experiment yielded a desired outcome. At Industrial Logic, experiments with our process have led us to continuous deployment, mob programming and ultra lean planning. Books like Experimentation Matters: Unlocking the Potential of New Technologies for Innovation and Little Bets: How Breakthrough Ideas Emerge from Small Discoveries help explain the benefits of rapid experimentation and learning.
Deliver Value Continuously
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.
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.
-
Evolve Solutions
Deliver Value Continuously
Make Safety a Prerequisite
Experiment & Learn Rapidly
In order to evolve solutions rapidly, we must organize people and teams, plan what to build, collaborate, integrate, develop and release. Modern agile shops get products or features in front of users quickly in order to rapidly learn from feedback. Evolutionary Design is key to such learning, as well as one of the best ways to quickly flow value to users. It's also an extremely useful way to uncover and fix collaboration and integration risks within or between product communities.
Embrace Change
Over the years, the agile movement has grown from a tiny group of pioneers in the mid 1990s to a large, world-wide body of experts and practitioners.
Along the way, some of the agile fundamentals got lost.
Embracing change is one of them, especially when it comes to improving your process.
Like Apple's hardware designers, modern agile innovators fearlessly questioned sacred cows, experimented with new processes, recorded successes and failures and carefully crafted better ways of working.
Modern agile is the result of courage, feedback, simplicity, communication and respect for people.
Do yourself a favor and explore this modern form of agile software development.
