Curiosity as a Basis for Solving Problems

To Kevin Kozlowski, being a good neighbor is about more than how you treat those close to you – it’s a life philosophy. Kevin goes out of his way to lend a helping hand, values curiosity when meeting a new person or problem, and understands the importance of laughter and humor. Even if it’s just a bad dad joke.

“There is always a way to solve challenging problems with a team. As a passionate servant leader, I have found it best to do this by lighting a fire within them rather than lighting one under them,” shared Kozlowski, who has sold and delivered technology solutions for over two decades. Recently, he helped a large insurance company strategize and redesign its website and mobile app with a focus on self-service. The goal was to reduce call center traffic to allow agents to grow their business instead of answering operational questions from their customers.

I have found it best to do this by lighting a fire within them rather than lighting one under them

– Kevin Kozlowski, Director of Business Development

“Kevin’s history of helping lead teams through a variety of changes and challenges, identifying value-added solutions to pressing problems, and approaching his personal and professional life with a genuine desire to help makes him a great fit for the Trility team,” shared Brody Deren, Chief Strategy Officer. “We are excited to have his presence in St. Louis as we continue to serve clients across the country.”

Having both sold and delivered transformative digital solutions gives Kevin a unique perspective to support clients in his new role with Trility. Our outcome-based delivery method means clients receive observations, recommendations, and options to iterate for the best, highest-priority outcome. Kozlowski will help build upon this proven approach and ensure we continue to deliver over and over again on our promises – meeting time, budget, and scope that aligns with business and technical requirements.

Interested in joining Trility, email or connect with Kevin Kozlowski on LinkedIn.  

About Trility

Composed of technologists and business consultants, Trility helps organizations of all sizes by providing outcome-based solution delivery. Clients appreciate that our teams solve problems contextually and bring their people along to ensure a reduced cost of ownership long after the engagement is done. Trility is headquartered in Central Iowa, and our people are geographically distributed. Giving our people autonomy to live anywhere and work anywhere allows us to serve clients from all corners of the United States and globally.

Product Design & Development

A Designer’s Toolkit for Developing the Right Software

In today’s tech industry, many development teams have been involved in projects where assumptions are made about customer or user needs. These assumptions might come from an executive, a stakeholder, or even tech and design leaders. Sometimes these assumptions work, but many times they are built without understanding the users’ needs – making the experience ineffective.

One well-known example about not understanding a user need was written by Jared Spool. A company had a $300 million dollar problem without anyone knowing. This company required registration upon checkout of their ecommerce website. Spool talked to users and found out they didn’t want to register with the website to make purchases. 

I’m not here to enter into a relationship. I just want to buy something.

Explained One Tester

Armed with this information, the team removed the registration requirement and made it optional for a user to sign in for purchases. This simple change generated an extra $15 million in sales in just the first month and $300 million annually. 

Strategic Impact

In our ever-changing world, validating that you are building software that is desirable, feasible, and viable is an essential part of business.

  • Desirable = What does the user need and why?
  • Feasible = What technology matches the project need and is accessible to the company?  
  • Viable = How will this application help business goals?

Desirability, feasibility, and viability are constantly evolving – rapidly. So, how do modern software teams build quality software effectively? By being aligned and focused on the problem, keeping things simple and iterative, and continuously learning together.

To produce quality applications, development teams must come to an agreement on the problem they are solving and continuously build, test, learn, and iterate together. All while keeping the end user in mind throughout the whole process. Without this foundation, the project is set up for inefficiency and waste. Here are a few strategies to help establish a baseline so your team frequently confirm what is being build does bring business, team, and user value. 

Team alignment on scope and focus

As a team, one of the first steps of a project is to frame the problem you are solving. The team must know “What” they are building but also “Why” it’s being built in the first place. This step sets up the range of solutions and is needed to make the project effective and sustainable. Breaking the conversation down to its simplest form helps the team understand the real needs.

Consider things like:

  • Our users are saying they need X, why is that?
  • When stakeholders are asking for X, what do they really mean? 
  • Is there a reason we’re using technology stack X? 

Defining the parameters of the project from the beginning helps refine scope, gives the team focus, and lays the foundation for team communication throughout the project.

Toolbox for Alignment

There are a few tools we can use to efficiently elicit this information. It’s important to understand what the benefit of each tool is:


Kick-off Meeting: The first project team meeting to align on problem statements and desired outcomes for the project.

Used for: Introductions, Understanding Project Requirements, Individual Roles and Responsibilities, Defining Problem Statements, Discussing Security Practices

(.5-1hrs Each)

Empathetic Interviews: Conversations with business leaders, users, and technologists that use open-ended questions to evoke specific experiences to uncover unacknowledged needs. Team can look for patterns on how questions are answered.

Used for: Understanding users perception, not usability.

(1-2hrs Each)

Personas/Archetypes: Data-driven insights about behaviors, attitudes, goals, and pain points to align the team on user experience priorities. 

Used for: Representing your target user(s). 

(1-6hrs Each)

Customer Journey Mapping: A visual representation of the process a person goes through to accomplish a task. 

Used for: Understanding the user flow to reduce friction when using the application. There could be different journeys based on user type.


  • Understanding the user intention, refines project scope to what is valuable immediately.
  • Up front discovery as a team leads to a better hypothesis of what is needed.
  • A team understanding user needs leads to better decisions by all team members.
  • Research helps a team understand where to build, not what to build.

Keep it simple – gather feedback and iterate

Once you have defined the parameters, it’s time to start solutioning or the “How” of the project. The Software Development team ideates a hypothesis for the project using knowledge gained from defining scope and focus.

Open-ended questions can help facilitate this collaboration:

  • What ideas fit the user needs, business goals, and technology for this project? 
  • What Security-by-Design principles or tools to leverage? 
  • What gives our users value from the beginning?
  • What is possible with the technology that we have available?

Once the team has aligned on a hypothesis, they will start building the easiest path from start to finish – often referred to as a Minimum Viable Product (MVP). Thanks to kick-off meetings, empathetic interviews, persona creation, and customer journey mapping, the team should be aligned on the project priorities. 

Successful teams can add value from the start and quickly deliver quality software by leveraging the user workflow exercise to plan what parts of the application. Once the simple path is mapped out, the team can begin an iterative process: 

00) Build something that adds depth to the application. 

01) Test updates with users. 

02) Demo the application with stakeholders.  

03) Make any updates that are needed. 

04) Repeat from 00.  

Building in small steps makes it easier for the team to be flexible when it comes to priorities, testing, gathering feedback and making changes. Gathering feedback and making iterations while you build will lead to less risk when the application is released.

Developer’s Toolbox for Iteration


Story Mapping: A method for arranging user stories to create a more holistic view of how they fit into the overall user experience. Sometimes referred to as a product roadmap. 

Used for: Outlining tasks needed to build a new product or a new feature for an existing product and arranging them into functional groups.


Agile: Iterative development methodology that delivers software to market (and value to clients) faster and with less headaches. 

Used for: Delivering secured software in small, consumable, production-ready increments. 

(30-60mins per interview)

User Testing: Interface and functions of a website, app, product, or service are tested by real users who perform specific tasks in realistic conditions. Example: Can our users get through the workflow without help? Are there sticking points? Is the language clear?

Used for: Information gathering about user experience to make application adjustments. 


  • Quality and security is built-in as the project is developed.
  • Feedback helps reduce risk of usability.
  • Value to the user, business, and the development team.

The team is always learning

Deeper Understanding for Company Leader

Because the team is consistently testing their app, their knowledge about users’ needs will become mature. Teams share this information with company leaders who can strategize, create vision, and make better informed product decisions.


Because the team is constantly thinking about the user, they notice they are making more objective decisions, which benefit the quality of the project. Teams develop a strong trust where ideas for solutions might come from any one of the members. For example a developer might have a great design solution and will feel comfortable discussing with the team. Not only does learning create quality output but it also creates a more fulfilling experience for your team members. Each role might overlap their responsibilities to educate, empathize and help build an effective application.


As the project evolves so will individual team members. Using this collaboration, Individual members learn more about the business, the users and technology making the employee even more valuable for their next project.

Toolbox for Learning

Paired Programming: Pairing up to work on development tasks leads to better code, diffusion of knowledge, transfer of skills and resiliency. 

Desire to Learn: Team shares articles, blog posts, podcasts, etc. and are always learning new things. 

Simple Discussions: Team is not afraid to ask questions or ask for help. Discussions with the team can clarify issues and bring forth a simple solution. 


  • Education provides value to companies, teams, and engineers.
  • Learning create more dynamic team members.
  • Psychological safety leads to better ideas and implementation.


Does your company align on scope and focus? Do your team practice quick iterations and make quality changes based on feedback? Do your employees educate each other and learn new things through challenging tasks? Whether we work as a strike team or consult client teams, Trility bakes strategic impact into our work.

If your team needs confirmation they are building the right thing, we can help figure out where you are at, where you want to go, and how to get there both strategically and tactically.


Trility Consulting Joins Inc. 5000 Fastest-Growing Companies List

When the founders of Trility realized they needed to form a company instead of individually contracting on extremely tough projects, they knew they’d bring value to clients and provide challenging work to those who joined the team. Little did they realize how quickly the teams and expertise they pulled together would make the Inc. 5000 list in their first year of eligibility.  

“Trility is a team of people always and only working towards one goal: Add the most value to our client experiences possible, moment by moment, each and every engagement. The by-products of that singular goal are revealed as satisfied clients, happy, healthy  teams, and cultural, company, and financial health. It is because of our teammates that we collectively, clients and Trility alike, experience value-based success.”

Matthew D Edwards / CEO

The Inc. 5000 is an annual list that ranks the fastest-growing private companies in America. Trility is eligible as a privately-held U.S.-based company with four years of sales with a minimum of $100,000 revenue in the first year and a minimum of at least $2 million revenue in the most recent year.

Trility opened its doors in 2017 with two Fortune 500 clients and has achieved consistent revenue growth by working with companies of all sizes and across 19 industries. Each of them seeking different solutions but sharing one trait – they view technology as the way to thrive amidst market, economic, regulatory, or competitive headwinds. Despite the challenges of a pandemic, Trility and its clients remained resilient. 

Edwards shared, “We are blessed to have great clients. We are even more blessed to have great people in our company who choose to become more each day than they were the day before. And they repeat this every single day of their journey with our clients and our company. I am proud to stand beside the people at Trility.”

Iowa-Based Companies

Trility joins 31 other Iowa-based companies who also made the Inc. 5000 list: VizyPay, MCI, Higley Industries, The Art of Education University, Pet Parents, Moxie Solar, Trader PhD, English Estates, Eagle Point Solar, Eco Lips, PowerTech, Heritage Group, Itasca Retail Information Systems, Heartland Roofing, Siding and Windows, Spinutech, MedOne, MediRevv, Trility Consulting, Dwolla, Highway Signing, Express Logistics, Schaal Heating and Cooling, Kingland Systems Corporation, JT Logistics, Clickstop, McClure, Peoples Company, Aterra Real Estate, GrapeTree Medical Staffing, Involta, and Ivy Lane Corporation.

Among the 31 Iowa-based companies, the average median three-year growth rate was 140 percent and total revenue reached $823.9 million. Together, this list of companies added more than 7,338 jobs over the past three years and remained competitive within their markets given 2020’s unprecedented challenges. 

About Inc. Media

The world’s most trusted business-media brand, Inc. offers entrepreneurs the knowledge, tools, connections, and community to build great companies. Its Inc. 5000 list, produced every year since 1982, analyzes company data to recognize the fastest-growing privately held businesses in the United States. Complete results of the Inc. 5000, including company profiles and an interactive database that can be sorted by industry, region, and other criteria, can be found at


Creating Wins for People in Their Career Journey

Sylvia Christensen is a geek at heart, a football aficionado, and Trility Consulting’s newest Senior Technical Recruiter. For more than 11 years in the technology industry, she has helped people take the next step in their careers. Syl, short for Sylvia, loves talking with candidates about past experiences and future goals to understand if the opportunity at hand is a good fit.

Recruiting is about more than a placement to Syl. It’s about the person who trusts her to play a part in their career journey. “It’s important to make the best cultural fit possible. Actively listening to the candidate and having a transparent conversation is central to making that possible for both Trility and the individual,” shares Syl. Proof of this ability can be found in her wedding guest list. They were people both her and her husband successfully placed over the years and established a lasting relationship.

Syl’s career is a combination of things she loves doing – nurturing people, talking technology, and creating community. We can’t wait to tap into her extensive experience, excitement, and excellence at Trility.

– Jennifer Davis, Vice President of People Operations

“People Operations exists to support and care for our team and Syl naturally fits in,” says Jennifer Davis, Vice President of People Operations. “Syl’s career is a combination of things she loves doing – nurturing people, talking technology, and creating community. We can’t wait to tap into her extensive experience, excitement, and excellence at Trility.”

As Senior Technical Recruiter, Syl’s ability to build lasting relationships with meaningful outcomes ties directly to Trility’s culture of building teams. By keeping the focus on client outcomes and adapting our continuous delivery to those outcomes, Syl and future hires help ensure valuable end results.

Interested in joining Trility, email or connect with Syl Christensen on LinkedIn.  

About Trility

Composed of technologists and business consultants, Trility helps organizations of all sizes by providing outcome-based solution delivery. Clients appreciate that our teams solve problems contextually and bring their people along to ensure a reduced cost of ownership long after the engagement is done. Trility is headquartered in Central Iowa, and our people are geographically distributed. Giving our people autonomy to live anywhere and work anywhere allows us to serve clients from all corners of the United States and globally.


The Long Way Around the Barn

There is usually more than one way to achieve your goals. Sometimes, the path to the goal is longer than it needs to be because we are all challenged with similar things: We often see what we know or see what we want to see. 

In this podcast, we look for options and recommended courses of action to get you to your desired outcomes now. 

Product Design & Development

Assessing Viability of a Technology Initiative

As a technology leader, you’re responsible for assessing projects, making decisions that add value, and creating opportunities for your team to succeed. You often spend time overseeing more than one project or initiative and are required to focus on two or more of the following types of activities:

  • Building and refining product roadmap(s) to confirm that future work is valuable to the organization and your team. 
  • Reporting project updates to managers or stakeholders.
  • Educating yourself and your teams on tools or products that have evolved to ensure projects remain viable.
  • Understanding what applications and tools are being used, how they talk to one another, and if they are integrated in a secure way. This focus might be highlighted if:
    • Your organization acquired a new company.
    • Your organization was acquired.
    • You inherited a new team or project.
    • You are new to the organization. 
    • You are shifting left in your security journey.

These responsibilities often have a two-fold focus – customer value and the company’s bottom line. On top of managing multiple things with this split focus, you’re working in a rapidly evolving industry. You are constantly assessing high stakes and high opportunities. Decisions don’t seem to slow down. They only keep piling up. 

Decision-making made practical  

Some people feel excited, anxious, or have different emotions altogether when making important decisions. Those feelings are valid – identifying what matters and what doesn’t can be hard if where to start seems unclear. 

You can leverage the Assessment Framework to understand where you’re at, where you’ve come from, and where you’re going. A robust project evaluation ensures all context has been discussed and considered – increasing the odds of product or project health, security, and viability. 

Ideally, this process will provide you one of the following recommendations:

  1. Project is working well.
  2. Project is not working well, but it is correctable.
  3. Project is not working well, and is not recoverable in a way that makes business sense.

This framework was originally described by Matthew D Edwards in his article, Distill What You See Into Action.

Download the Assessment Framework to determine the health and business value of your initiative. For even more accurate results, include your team to consider and broaden your perspective. 

Making Your Assessment Actionable

If you desire an outside perspective for assessing the health of your project or initiative, reach out to Trility. Our teams can help by conducting the assessment and leading a discovery process, building out an actionable roadmap, and partnering on areas of work where your team may need to leverage future-state skills.


An Engineer’s Journey to SAFe

Show Highlights

The creator of the Scaled Agile Framework, known to many as SAFe, sits down to discuss what it means to develop and invest in a framework that encourages engineering rigor, predictable and repeatable outcomes, and personal fulfillment. 

Dean Leffingwell, a methodologist, author, entrepreneur, shares his life’s journey, starting with how Sputnik sparked his passion for space travel, then led him to biomedical engineering and the life of engineering and delivery patterns, frameworks, and ultimately delivering value.

Read the Transcript

0:00:00.0 M Edwards: My guest today is Dean Leffingwell, a methodologist, author, entrepreneur, and creator of the Scaled Agile Framework, known to many as SAFe. We talk about what it means to develop and invest in a framework that encourages engineering rigor, predictable and repeatable outcomes, and most importantly, personal fulfillment. Join me as Dean takes us through his life’s journey, starting with how Sputnik sparked his passion for space travel, thereafter biomedical engineering, and the life of engineering and delivery patterns, frameworks, and ultimately delivering value.

0:00:36.2 D Leffingwell: “My life was a living hell. Everything was painful. I worked all the time. In pager days, I had my pager, now I’m always on the phone.” And he said, “Since SAFe, I go home and rest knowing that things are in pretty good shape.” What’s that worth? That’s the kind of thing that gets you up the next day to say, Oh, I think there’s more that can be done. Because this guy got his life back, because now there’s some routine, there’s some rigor, and so some visibility. So he knows where his systems are, he knows how they’re performing, and his people know that they’re getting the psyche rewards for a job well done. And that’s the real purpose behind SAFe, it should be fun to build these systems, they’re really cool systems. We shouldn’t feel bad about it. Yeah, we make mistakes. So what? But nobody else could build that system that your company just built. It’s never been built before.


0:02:23.2 M Edwards: So, Dean, thank you for taking the time to get together with us and teach us. We appreciate it in advance.

0:02:29.4 D Leffingwell: You’re welcome, thanks for having me here.

0:02:31.2 M Edwards: So for fun, I want to learn about you and your journey and the things that have made you smile and maybe some of the things that have made you frown along the way, and how you’ve evolved, but can you tell us what has motivated you to start the journey of creating something to teach, to enable, to equip people? In other words, at least in my journey, I’ve been influenced by Rational Unified Process. I’ve been influenced by lots of things, Agile, and then also including the evolution of Scaled Agile. So those are only some of the things I’m aware of and that I’ve personally found value in. I’m curious, and I think a lot of us are curious, as to what along your journey made you say, My gosh, somebody needs to do something about this, and I’m the guy that’s going to give it a shot? 

0:03:19.5 D Leffingwell: It was kind of incremental. And I start out with a stroke of good fortune. I talk to young people, not every day, but every few months or so I meet somebody, and maybe it’s a child of a friend or a grandchild of a good friend or whatever, and we talk about what motivates them, and they want to know, Well, how did you do what you do? And I said, I started out lucky, I always wanted to be an engineer. So I kind of harken back as I think more through it more deeply, back to Sputnik days, and I was, I think, nine years old when Sputnik was launched. And it was all over the TV, and it was the arms race, it was the space race, it was new and different. We didn’t know what life on this planet would be like in 50 years hence, and we didn’t know that we wouldn’t also be on other planets. And for me that was so exciting to think about participating in that larger journey of mankind. Now, it looks kind of silly at the time, but we didn’t know that we’d still be on one planet, we didn’t know necessarily that laws of physics can’t even get us to the moon, other than on a rare occasion.

0:04:27.5 D Leffingwell: But at the time, it was like, “Wow, this world can evolve really, really in crazy ways.” So I was a scientist and engineer; all my life I’ve wanted to be an engineer. I was pretty good at that, I felt really comfortable around quantitative methods, and got really comfortable with the engineering sciences. So through my early career and early development, had a really small town high school, then I went to really good schools. I went to Illinois Institute of Technology, I went to University of Illinois and I got my degree in, you’ll be shocked, aerospace engineering, because that’s where the people that were designing the rocket ships and the fun things that were going to go up into space. I graduated right at the time when it was post-Moon launch and people were going, well, what do you do now? And who can afford that kind of investment? And the whole space scene kinda collapsed. It was one of those many zenith and nadirs. So that wasn’t particularly effective. It’s like, Okay, I’m probably not going to work in aerospace engineering. But in my graduate studies, I found a mini-computer in the corner, pretty much literally. It was a Nova 1200 that had been shipped to us. It had no software and nobody knew how to use it.

0:05:40.1 D Leffingwell: There was a manual, I think, but I don’t even know if that was the case. And at the time, a part of aeronautical engineering I was interested in was what happens in space to people. It’s very good to think about this piece of titanium out there, but what happens to people? And at the time, we were very early in just trying to understand the physiology of space travel. And our machines to do that were all analog computers and big punch cards; I don’t even remember how they work but they were awkward as heck. And there was this mini-computer in the corner that nobody knew how to program. So I picked it up and started just self-taught programming, I never took a class in programming other than one Fortran course, and started to use that to do some physiological monitoring. And indeed, co-founder was at least asked to join my first company and we built mini-computers to monitor people’s physiology, basically one of the first EKG machines. And that was fascinating and interesting, and I started my first company down that path.

0:06:44.7 D Leffingwell: So the company that I started earliest was Rela Inc., and this is back 40 some years, we did biomedical equipment development. We could put a computer in anything and hardly anybody else could. Well, at the point that I started becoming a programmer, there was this weird juxtaposition in my mind, which is that when I studied aeronautical engineering and physics, everything had a certain logic to it, and the laws of physics predominated. You built a bridge and it stood up or it didn’t, right? And you could actually calculate that. You can say, okay, it’s going to stand up for these reasons, it can withstand this. So it was very predictive, and that was comfortable for me, I felt like science should have some foundation. And then I was programming computers, and I could make a single bit error and bring the computer to its knees. And we were building systems for people, life-saving systems and life-enhancing and life-extending systems, it’s like, how does it work that a programmer can make this machine not work for a person without anybody even seeing the code? 

0:07:52.3 D Leffingwell: So there was no physics or engineering in software development. And I think to a certain extent that’s really great, because it means that the creative art and the people practice will never leave it, but it’s also not super great because we’re trying to build an MRI machine or an electrocardiogram system or an infusion pump, it better damn well work and it should do what you want it to do and nothing else.

0:08:17.1 D Leffingwell: So I became interested in software quality really early, as a programmer. It’s like, This is going to go on a person. I’ve done my best job, but am I going to make a mistake that kills people? And so I started migrating to really the study of software engineering practices, and early texts I’ve still kept, software engineering handbooks, and started to think about what kind of rigor you could add to this creative process? Because it was clear the future was all bits and bytes. The digital age was obvious for me 30 or 40 years ago. But there’s no laws, no laws of physics, and you could do anything and that was incredibly creative, and scary as heck. How do you know you have it right? So, well, does it perform to the requirements? Well, what are the requirements? Well, we really need to write those down, because this infusion pump can’t run away and it’s going to have different viscosity. So I migrated to the kind of the front end, because if you could get the requirements right enough, then you could build a medical system that worked. And that was waterfall-based, I make no apologies for it. Waterfall, God is here.

0:09:29.0 D Leffingwell: So we were really rigorous. And I remember we had kind of process flow charts that were very waterfall-driven, that we actually sold to our clients. Said, We’re not going to write any code before it’s time. We’re not going to design an arbitrary system, we’re going to spend the time upfront to get the requirements right. And we look at all that kind of now as a bit silly, but yet every system conforms us to its requirements whether you know them or not. So the discipline at the time was very waterfall-driven, and I spent probably a good 10 or 15 years writing about it. OO (Object Oriented Testing) came along, and that started to change things a little bit, because it started to change the way in which we thought about the software. We started thinking about modeling the actual dynamic system. And then all of a sudden this rigidity of the fully prescriptive nature didn’t fit as well. I was trying to model the dynamics of this system… I remember Mike Devlin on stage saying, “When did we get the arrogance to believe that we can invent this new world class system in one swoop?” I mean, who does that, that’s just… 

0:10:36.6 D Leffingwell: And you look backwards, you go, That’s kind of a stupid plan, is we’ll figure everything out up front, we’ll write a bunch of code and it will work. And that led us to iterative and incremental development, and RUP which is now old-fashioned like waterfall and easy to criticize. It’s like, Yeah, well, turboprops aren’t very cool when you’re looking at a jet next to it. But the reality is that was the technology at the time, and it was the first codified model that says, We’re going to take multiple whacks at this. Now, there were big iterations. They were four and six weeks, and because the constructs that we had around its inception, elaboration and construction, transition seemed sequential. The reality is it was interpreted as a waterfall overlay on a series of iterations, so there were like elaboration iterations. Okay, we now look backwards at that and say, Well, we could do more than liberation and iteration, but that was the first structure codified, and frankly promoted to the extent of being useful. At Rational, what I learned was to how to develop what I think really is the crux of the sign of the IP, the science inside our work, which is heavily peer-reviewed work by knowledgeable experts.

0:11:50.4 D Leffingwell: And I had the unique fortune of, not managing Grady, Jim and Ivar, because they’re not manageable, and they would tell you the same, but they were in my department’s budget. [chuckle] And what I did was I observed how they worked and thought and frankly argued, and how they came to conclusions like what the shape of a cloud would be. And once that decision was made, they moved on. Now, in the Booch method, an object was… Shape of a cloud, sorry. In the Booch method, the object was in the shape of a cloud, it was kind of cool. But in OMT it was a rectangle. Well, they picked a rectangle. And those decisions were critical decisions, but they made them and they moved on. And then when they decided that that’s what we’re going to do, then three people said, I’m going to represent an object using this icon, now I can think about modeling. So I saw them do that work, and when I joined Rational, very smart company, very proud of my time there and the people there, John Love at the VP of Field Sales came to me at literally the celebration party of acquisition and said, Well, what do you want to do now? And I looked at him like as a trick question, and I said, What do you mean, don’t you want me to run my old business inside Rational? 

0:13:11.3 D Leffingwell: And he kind of smirked a little bit and he said, “Dude, we’re pretty sure you don’t want to do that.” [chuckle] And he was right. I mean, the last thing I thought was my next ambition would be to run my same old business in a larger company. And I said, “I find really interesting this intersection of modeling, Objectory and tooling, and I think there are some amazing potential software engineering disciplines in there that could really improve outcomes, and I want to do that.” And they said, “Okay, you got it.” So I picked up what at the time was Objectory, the UML team helped promulgate that, started merging the two so that the UML knew about the process model and the process model knew about modeling, and 4+1 views, okay, you could have 71 views of architecture; 4+1 was memorable. So I saw how they created an IP stack, and because I also ran Rational University was responsible for where we turned those ideas into courses. So the root of what we’re doing at Scaled Agile right now is a business model of this as, if you can get a group of like-minded independent thinkers to agree on a concept and peer review that heavily…

0:14:24.0 D Leffingwell: There’s a strong probability there’s really good IP in there. And that if you can promote that and promulgate that, people will use it. The neat thing about that part at that point, I’d been through a couple of businesses, started two or three, had seen methods and practice evolve, and there was this Agile Manifesto out there which was kind of… You could smirk at that, too. Yeah, we don’t need your stinking requirements, and it’s the home of Dilbert. But I was completely free of any corporate trappings. So I met you about then, Matthew, because you were running one of the sharpest XP shops. I remember it well, at the time, and I remember the instrumentation that you had. I remember the big daily stand-ups, I don’t know if you do, but you’d have 20 or 30 person in the daily stand-up. So we didn’t have… You didn’t have the notion of the scrum team, but you understood XP. I migrated to it, and here’s why. Because it’s, A, it’s more fun, and, B, it produces better quality code. But I never lost my zest for highly reliable code. So I met people like you. I met a guy by the name of Dave Muirhead, who taught me a little bit of XP. He wrote some code, I pretended like I was peer programming, in reality I was just watching him code. And then he’d stop and put some more code together. What’s that? And he goes, Well, that’s a test for the code.

0:15:40.7 D Leffingwell: And I said, Well, why are you writing a test for the code you wrote, don’t you think it works? And he goes, “I know it doesn’t work, I just wrote it, how can it possibly work? I know it doesn’t work. And I’m… Before I’m going to take accept responsibility,” and those were his words, “for this story,” that was the vernacular of XP, “I’m going to make sure it works before I put it in the baseline.” And for me that clicked as a discipline, and said, Wow, this is not… This is not some really lightweight, we don’t need no stinking requirements, I’m going to code what I want and hope my boss loves it. This is the most seriously disciplined, high quality craftsmanship being applied to development. So all of a sudden waterfall and RUP looked old and stale, Agile was king. I got the good fortune to meet you and lots of folks like you, we’ve stayed in touch over the years, lots of mentors, and then I started trying it. Now at the time, I was kind of an investor and advisor in about a half a dozen software companies in Colorado. And that was convenient because Rational was a pretty tough road warrior gig, and my kids had grown up with me on the road a lot, so I got to stay home.

0:16:50.7 D Leffingwell: And then I just became an Agile coach like you. I did the same thing you did. And I started seeing the difference it would make, even in RUP shops. It would be, in six or eight weeks you could change the culture, the attitude and the results with Agile. Agile was like an order of magnitude, better instantly. And for me, as a student of these things, it’s like, Wow, look at that. I’m sure your experience as well, it doesn’t have to be a monologue here. I mean, we met up at probably about that same junction of our careers.

0:17:22.8 M Edwards: Sure, Oh, I can tell you, what I really loved was the idea of order. Like a predictable, repeatable opportunity to understand why. So if someone said, Go do this, and then I go do these things and I get this result, I can understand why. Whereas without that, it was often times heroic, where you have people who get out of bed with varying levels of energy, or they have variable things going on in life which impacts their contribution for the day, and why isn’t always immediately observable. So I loved RUP because it gave me an opportunity to understand the value of a framework, or a value of a thought paradigm. I remember going to the classes, I remember cherishing the books. I know it sounds a little silly, but I got the books, I read the books, I loved the books, and I tried to figure out how to add value using those ideas. My evolution from there was really what I came to understand was patterns matter, but discipline matters, and the easiest way to eliminate waste from anything is transparency. So my evolution from RUP into what was eventually these behavioral practices that we generically call Agile, the Agile Manifesto, what I loved about that transition and especially when we got into extreme programming, was it stripped everything down. So what did not change was patterns.

0:19:04.0 M Edwards: Patterns must exist. A healthy heart has a predictable, repeatable heart rate. An unhealthy heart has an erratic heartbeat. Similarly moving from RUP, which enabled a healthy heartbeat, to XP, which also enabled a healthy heartbeat… To your point, was a giant transition, as if on steroids, because it stripped everything down to, “We’re all standing here in this circle talking about this thing, and either you know what the thing is or you don’t. Either you committed or you didn’t. Either it worked or it didn’t.” It just stripped us all down almost… To embarrassingly transparent with each other, like, “Oh my gosh, my code actually sucks,” or, “Oh my gosh, I worked really, really hard today and delivered nothing, but I gained lots of knowledge.” I loved the transition to XP, but what transcended RUP to XP for me was the value of patterns, discipline, and transparency, and those three things are what I found amplified a high-performing team.

0:20:13.6 D Leffingwell: I remember in your shop, we’ve talked about the benefits of transparency and discipline and patterns. But you know what? Creating big solutions that work is really fun, right? So the engineer in us and the kid in us that says, “This should work, and that’s really fun.” And it doesn’t mean it isn’t hard, but hard and fun have a correlation when you’re getting results. So when the outcomes improve with Agile, it’s more fun. We grew up in systems where it was easier to write code that didn’t work, to be discovered later, than it was to change the requirements. That’s not fun, right? That’s like, you know you’re wasting your time, and you go home at night feeling bad. But you shouldn’t have really do that with Agile. I mean, there are constraints, and life is imperfect, but wow, if this doesn’t make sense, you’re not going to do it in Agile. If the PO says, “Let’s do this.” And the team goes, “That makes no sense.” The team’s going to be listened to, and it has a innate empowering element that I think unlocks the intrinsic motion… Motivation of why we do what we do. I have an avatar that’s a little kid with a colander on his head and some tentacles sticking out of it.

0:21:25.9 D Leffingwell: I’m still that kid. That kid wants to have fun, and I will tell you with Waterfall and RUP, in both cases, they were helpful and rigorous, but I don’t remember the fun. And when I got into shops like, “Here’s where you guys had a pig in a poke,” there, using an idiom, right? [chuckle] Handed this big blob… It was still fun to make progress against that, and to know you’re making progress in a predictive way. So a sense of order and the ability to have more fun… And when I saw that fun and discipline go together, well, that was new. I don’t remember that part before. It seemed like discipline was the opposite of fun always, and fun was the opposite of discipline. Well, it’s not the case in Agile. So when you and I met up, I was doing some consulting and finding shops like yours and trying to figure out what was working, listening more than talking. Now, I had enough experience that I got paid to talk, too, but that just got me in the field to listen to people like you that were well advanced in your thinking, where I was…

0:22:26.2 D Leffingwell: But I started then applying basically this Agile method at scale. And because I wasn’t accountable to anybody anymore… There was no brand on my shirt other than what I believe to be true that day. Basically, I stripped down to XP, and I tried it in a couple of shops, just pure XP. And guess what? It didn’t work. It didn’t scale. It lacked the architectural patterns. It lacked the coordination and the cooperation. It lacked the fact that if you’re building a system, the system’s behavior is more than the sum of its components. It’s to how those components interact. And if you don’t care about those interactions, you’re going to create a system that’s basically crap. So scaling Agile a team at a time didn’t really work. And we had issues with alignment… Why we’re building, what we’re building. We had issues with architecture. So little by little, I started adding the things in, not to kill Agile, but to say, “Look, we need to architectural governance over the system. There’s 400 people building this system, and it’s monitoring a huge distributed network that’s basically mission-critical. We gotta talk about this, and we need to work it out.”

0:23:43.4 D Leffingwell: So through that process, then, I wrote my second book… Well, in the Agile space, called Agile Software Requirements. And the reality is that book is really called Scaling Software Agility Now Actually Working, but that title wasn’t any good. So it has requirements bent. It’s not a requirements book. It’s a book about how to build a really big system using Agile, and that was readable enough and knowledgeable enough that I started getting invitations to big companies. Companies like Nokia Corporation and Computer Associates, DB Tools Group, and they said, “Can you help us scale Agile?” I said, “I’ll sure try.” I said, “I’ve written what I know, but we’re learning every day.” And then in 2010 or so, I was at an Agile Alliance Meeting, and four or five people that I knew and had worked with kind of interactively said, “Can we meet?” And I said, “Yes,” and they said, “We’d like to start a company.” I said, “I’m not starting any more companies. I’ve started my last one. My last one was one too many, and I don’t want to do it.” And they said, “But there’s… But I think we can help the industry here. I think that you’ve got in this book and in your mind and in our minds a way to commercialize this,” to use the crass term. “And to frankly help more people and build a big business.” So I threw in the towel. I said, “Well, I don’t want to start the company. You guys start the company. I’ll license my IP.”

0:25:10.1 D Leffingwell: And then down the road, of course, the founders have their inevitable ways of trying to figure out what’s going to work, and then I rolled my IP in the Scaled Agile. And that was only 2014. So the reality is, as a business… a combined business, we’re just seven years old. But what we discovered is that those books don’t stand alone, and even we can’t consult enough, and the reality is, is a change of this type has to happen by the people doing the work. And what people are not shy about is they will invest in themselves. So we started to understand the training, like the stuff that you took with OO and the stuff in Agile, was a way to monetize and grow the business. So one of our guys built a website. I built the courses. Another founder went to some early partners and said, “Could you work with this and do service delivery?” Because we were of such a belief that scaled Agile is going to change everything. And it did. And we knew that what could 10 people do in Boulder, or even a 100, or even a thousand, and we said, “We don’t want to be restricted to that. So let’s just focus on the IP and initially training.”

0:26:30.1 D Leffingwell: Now, we’re much broader than that now. We have a complete operating system that people run. It’s kind of like Toyota production system. You don’t learn it. You run it. So we’ve moved on in our thinking, but the training franchise has been super powerful for us, and the training was a cash flow we needed to grow and scale. And then as we got successful, the larger partners… the C-Primes in Accenture who initially thought, “Who are you guys? Why would we follow you?” Well, their customers were following us, and their customers were saying, “We want to work this way. We like this body of knowledge. So if you want to support us, please work this way.” So then over time, we grew the partner network. So the partners do all the service delivery and that means that we’re a highly leveraged model. We’re not as big as some people think, but we have a really big impact, and at the last summit we announced one success story, which is over a million people have taken our classes, and that’s basically… And it’s not even the seven years. That’s in the last five. So I didn’t predict that success. I just believed that it was a better way of working, and then I believed that if people find a better way to build the world’s most important systems and they’re digital…

0:27:40.3 D Leffingwell: There’s going to be some value in that. And it turns out there has been value in that, and we talk about what we do through our case studies, but I’ll also tell you there’s hardly a day goes by at work that somebody doesn’t lobby in an email or something in our internal Slack newsletter that says, “This big pharmaceutical company that isn’t talking about SAFe just did this with SAFe,” or more public companies and more public entities like the FBI criminal justice information system says, “We’re using SAFe and we want to talk about it, ’cause we think it’s important.” And we get such incredible rewards from that that… You know, you talk about ups and downs… Running a business… I was a CEO up until two years ago. It’s not easy, and your work every day isn’t easy. Stuff happens, right? Not everything you do at work is fun. But if the work you’re doing is meaningful and creates the big F, then you can suffer through the small Fs. Whatever they have… The restructurings or… My case, too much debt early in life for the companies. You suffer through those because you’re on the right mission. So I found about five or six companies, depending how you count them, all but one were doing exactly the same thing.

0:28:54.7 D Leffingwell: How can we help people, mostly people building the world’s most important systems, do a better job? Because when they do a better job, they’re happier, and when they’re happier, they do a better job, and then they’re again happier. There was this virtuous cycle, and I will credit Agile, is certainly the name of the game today. I know some people… I remember one company that said, “You can help us, but do not use the word Agile here.” I mean, it’s not a pure play, if you will, but Agile unlocked that in a way that, in the course of my career, nothing else did. So when I talk about Agile, I teach classes, I start with the manifesto, and some of those guys aren’t fans of me because of the way we’ve scaled Agile. They think that maybe… Maybe they have different paradigms. I won’t even guess what their view is.

0:29:41.4 D Leffingwell: But the large enterprises that have 1,000, 10,000 people. Places like the Air Force, Portia Corporation. I’m just making sure I’m talking about ones that are published case studies – Global TV in Brazil, People, MetLife – those are the companies that have found a way to us, and from a business model perspective, it’s kind of cool when the stuff that you provide is most appreciated by really large enterprises. There’s more people there. So that’s another thing you couldn’t really plan, which is that we’ve created a model for scale, and mostly the big enterprises are the one to scale, so that kind of brings us to the current state, which is that the other thing. We do not suffer from the arrogance of our own ideology.

0:30:32.0 D Leffingwell: I look back at Version 1 and 2 and 3 of the big picture. I can hardly look at it, and I know right now in version 5.1, I know it’s… Not exactly, but I have a whole set of things we want to do different. So we started revving the framework really frequently, and I remembered about version 3, somebody came along and says, “This was like the smartest thing you’ve done, revving the framework,” and to me, it was like, “Well, how could I not do that? How would we pick a model that worked in 2009 and see it applies in 2021?” So we’ve been able to put together a team of people… Mostly they recruited us or me, the people on my team found our company and said, “You’re doing what I want to do,” and we have the larger group of SAFe fellows out there that are good agents and add value. We always go to them first. Also the SPC trainers, we have about 100 of those. These are our peeps. They’re our customers, and they’re filled with good ideas. So when we go to make a change now, it’s brutally abused by every opinion out there, and then we integrate and we decide, and we pick a thing that’s never perfect, but it’s better than it was before and continue to evolve.

0:31:47.3 D Leffingwell: Sitting here today, we’re just filled with ideas. There was a little debate in Slack this morning about… It’s not quite the right label for that, because that’s not the sentiment anymore. Okay, how hard’s it going to be to change a label that appears in 1000 pages of coursework? Really hard. Okay. Let’s get over it. Let’s go on. Let’s go on from there. So that kind of brings us to the current state and our continuation of essentially the same business model, the same strategy, which is, “When will the world not need really, really more and more capable digital systems?”

0:32:27.6 D Leffingwell: I don’t know. I can’t imagine that time. When it is, then if that happens, I’ll definitely be obsolete. But in the meantime, we’re good to go, because the problem has always remained ahead of us. Now the Air Force talked about their big program, and it’s a big material program for our nation. There’s 10,000 people engaged. Well, some might say, “Well, de-scale that.” Well, you try to de-scale that. There are seven vendors. There’s a huge supply chain. There’s a legacy of 10 million lines of code. I’m not going to solve that problem with two pizza teams. This is the problem we’re given, and this is a problem we need to address, and that takes a system of scale, and that takes big patterns, and it takes patterns from the team level to which… You know, I’m on an Agile team. We think often about our practices. We run retros. We don’t run them every two weeks, that’s… Honestly, I think that’s silly.

0:33:18.1 D Leffingwell: But every quarter we say, “What did we learn that we could change?” That’s part of the basic Agile, but that goes all the way up to the portfolio level, where the portfolio teams in our organization and others now, every couple of weeks, look at the backlog, and say, “Are we making the right investment?” So that Agility now scales from the individual team level all the way to larger enterprise, and recently we have this… It’s called Portfolio. Portfolio’s an enterprise portfolio because they’re really big companies with a common way of working, and they discovered that the things they want to do next cross multiple value streams. If you’re in the business of making vehicles, that’s an entire ecosystem. That’s not constrained to the ABS system. So these cross-cutting concerns are also challenging and very difficult because we have to impose those cross-cutting concerns. Some are safety-related, or, let’s say, GDPR. Nobody wakes up and says, “I really want a day today to spend all my time figuring out how to make sure that we can support the right to be forgotten.” That’s actually a ton of work. But that comes with the territory, and therefore we have to scale to make sure that the large enterprises that have these challenges can find comfort in our set of patterns and know that we’re not resting.

0:34:31.2 D Leffingwell: And initially, I think there were years where it’s like, “You guys changed the framework again? What. You’re killing me.” But lately when I interview our key stakeholders, they go, “Well, that’s what you do, and that’s what we do is we evolve with you.” So we’ve lost the notion that there’s an answer. And we’ve found the notion that there’s a Best Current answer, and I like to make jokes about SAFe Version 8, because I say it’s going to be a pill. You’re going to take a pill, and every developer write the test first, and every leader will be an empowering decentralized decision-maker. Well, prior to the pill, there’s a lot more we have to put into SAFe, and that’s what the team and the whole company is dedicated to doing.

0:35:13.2 M Edwards: Well, it actually makes sense that it’s a versioned, living, evolutionary idea, because everything else that we’re talking about is versioned and evolutionary and always changing. So it would be, sadly, ironic if the behavioral framework that we’re using to build a system that’s a living, changing system itself doesn’t ever change. So I love the fact that it’s versioned and changing. I love the fact that you guys are doing retros and challenging ourselves, and it sounds like you’re saying, “Hey, this made sense yesterday. Does it still make sense today? And what do we need to change?” And the fact that you’re not gold plating or worshipping your own product is actually outstanding, and is why you’ll continue to see how to add value. That’s wonderful. I have loved watching the evolution of SAFe. I have also enjoyed hearing all types of commentary from different sides, whatever, dodecagon, you pick whatever the shape is, but so many different views.

0:36:15.6 D Leffingwell: I enjoy it, too. [chuckle]

0:36:19.9 M Edwards: I can tell you this. I have been the CEO of this company now… It’ll be five years in January. And I’ve done a lot of different things in my career, a lot of privileges I’ve had to work with awesome people at awesome companies, and so on, all privileges. All growing opportunities, and sometimes joy, sometimes not so much joy, and mixes in between. But I can tell you, in my consulting career, I had opinions and thoughts that I communicated sometimes in consulting engagements about how a CEO or the C-Suite should do their job. And you know what’s changed now that I’m a CEO and part of a C-suite is some of the things that I said before were logical and deductive and reasonable, and also not sitting in the trench of warfare and not standing in the mud. So I could make health observations and organizational change recommendations, and I could facilitate and foster and encourage and enable change, but that’s different than being the CEO sitting in the chair.

0:37:31.7 M Edwards: And so what I’ve realized through time… And it’s interesting how I can continue to age and still discover I don’t know as much as I thought I did. But in these last five years, I’ve discovered that I don’t actually know as much about being a CEO as I thought I did, and similarly about software, I’ve discovered that technologies continue to change. Perspectives on how to build something useful changes. The frameworks I have found to not always exist, and if they do, they’re static, for example. So all of this talk to just say, one, I realize that there are variable opinions on things, but you know what? There are opinions on XP. There are opinions on Crystal, opinions on Scrum, Enterprise Scrum. There are lots of opinions, but to try and build a product or a solution that is actually useful is its own endeavor. Now to try and build a system or an ecosystem at scale is an additional complexity.

0:38:41.0 M Edwards: And so what I like about what you’ve done, is you haven’t said, these other ideas, those are bad ideas. That’s not what I’ve heard from you and I’ve known you for quite a while, that’s never what I’ve heard from you. What I’ve heard from you is, I get that, I like that, now how do I scale it? And that’s why I like the evolution of SAFe. Now you have other conversations, right? How is it implemented? How is it being used? How are they evolving? What’s the general health of the culture that’s using it? What’s the health of the products and services that are being used? There’s just so many different views. But a question for you on that is, in this journey you’ve created something with the desire, not alone, not in a vacuum, but you’ve been a creator of something with the intent of enabling and equipping people; is there anything in particular that you would recommend to folks that haven’t considered SAFe? For example, Hey, here’s what SAFe is, here’s why SAFe is created, here’s how we have envisioned that it’s utilized as an enabler, but in order for you to find the most value in this idea, you really need to understand these fundamental ideas first, or else you’re never going to get the value of the entire SAFe framework, for example.

0:40:04.2 D Leffingwell: And I think our best shot at that is the principles in SAFe. And we didn’t actually start with that, to be honest, we were probably at version four or so before a few of us said, No, wait, there’s some really common underlying principles here. And we spent some time and we drafted nine, and that became 10, and I remember the discussion with marketing, because when we added… How do you add a principle? Did you get it wrong? Well, we missed one. Okay. Well, what about all these cups that we have with the nine principles on it? Explaining really complex things simply is a gift, and I honestly don’t know if I have it. When I look at the framework, I can look at it two ways. It’s a gift to reduce it to a page, and it should be a gift that it says I can’t explain it even further. But I have trouble explaining it either, I can’t distill it down further. It’s time to market and employee benefits, those are the why, but can you describe SAFe more simply? I struggle with that. Because at a point where we decided it’s eight and a half by eleven, that’s what you get, everything else is behind the scenes. So I don’t know if SAFe is overly simplified for the problem domain, or it’s too complex, I can’t tell.

0:41:12.8 D Leffingwell: What I can tell is people seem with enough effort to be able to get it and make it work.

0:41:16.8 M Edwards: Well, there’s the latitude in there to think. And so for the environments and cultures that actually enable people the opportunity to evaluate and think and decide, in my opinion, you’re able to take the frame… Just say you take the eight and a half by eleven and look at the picture? I believe that it leads you down the path to say, Well, what is that? Why is that there? But the other interesting thing about people in general is, lots of people, in my opinion, me included, and in particular, things make sense to me when I have a need to understand it. But until I have a need to understand it, it’s fuzz. And so you can look at that eight and a half by eleven and not know why you care yet.

0:42:02.1 D Leffingwell: There’s probably another bias that I’ll share here in this audience that I don’t call it specifically very often, is my first company basically did R&D for hire. And that’s not a recommended business model, okay? [chuckle] Because your customers want fixed, known certain things, and yet you’re inventing. And you can’t just say, “Well, we’ll invent and it’s going to take a while or it’s not and you can pay us whatever cost.” You can’t really do that. So, at the same time when we were structured in these waterfall situations, and even non-waterfall situations I ran into just the other day, where there’s a big SAFe shop that’s really struggling, and the reason they’re struggling is they are so over-scoped that they just don’t have permission to say no. So their PIs are way overloaded and they’re really, really struggling. And frankly, after 20 years of developing some really cool stuff, and going home as a CEO and as a developer feeling kind of beat up, I started saying, This just doesn’t seem fair. Nobody else could build that infusion pump or that adventure ride; why do we feel bad? We’re being abused for the defects and the overruns. It’s like, This is one of the world’s coolest systems, it’s brand new.

0:43:18.8 D Leffingwell: It’s basically a beta for a brand new thing. And that again came back to my motivation, that says, We as a development community, be a little bit personal, when we build these good systems it should feel great. [chuckle] And you should go, Wow, that was really cool. Are there issues? Absolutely. And did we miss some things? For sure, but it shouldn’t be constant beating about the head and shoulders because you couldn’t invent FOO in one year. We gave you a year to invent FOO and it took you a year and a half. Okay. We’re mad. Sue me. [chuckle] There was never a FOO until we created it. So my innate empathy is with people in the trenches who have this intrinsic motivation to create great work, whose systems and processes prevent them from doing that, and who end up knowing, no matter what I do, it won’t be enough. And at this shipment we’re going to take a beating. And they’re not even admitting to the board, or we’re not telling the customer. We can’t tell our government client that this dog isn’t hunting. That’s just not right. I don’t think that’s the right way to treat the human capital. And it’s not that we’re special…

0:44:32.1 D Leffingwell: We are kind of special, we know how to code, that’s good. It’s that every human being deserves to be fulfilled. And when we pick a discipline like this that can create great systems, that should be fulfilling too. And when it isn’t, that just seems like a crime against technology and nature. So I spent my career just trying to improve that a little bit. And I think on the point now where we see in the results people saying, We couldn’t have done this without SAFe. And it’s like we used to… I remember one recent vignette, not public, that just came in on the Slack channel, that said, “I’m basically a CIO,” or VP of Dev, I don’t remember, “My life was a living hell. Everything was painful, I worked all the time. In pager days I had my pager, now I’m always on the phone.” And he said, “Since SAFe, I go home and rest knowing that things are in pretty good shape.” What’s that worth? That’s a kind of thing that gets you up the next day to say, Oh, I think there’s more that can be done. Because this guy got his life back, because now there’s some routine or some rigor, and so some visibility. So he knows where his systems are, he knows how they’re performing, and his people know that they’re getting the psychic rewards for a job well done. And that’s the real purpose behind SAFe, is it should be fine to build these systems.

0:45:52.3 D Leffingwell: They’re really cool systems. We shouldn’t feel bad about it. Yeah, we make mistakes. So what? But nobody else can build that system that your company just built. It’s never been built before.

0:46:02.1 M Edwards: Right on. Well then, how about this. Closing us out. Across your journey, and pick whatever parts make sense or where it makes sense, thematically, I mean, are there some things that you have learned that you would share? And when I say learn, I’m saying in the context of you’re a gent that started out desiring physics and engineering and learning programming or development, and saying, I like to understand this framework, this structure; if I do this, then this. Your journey has led you to say, Hey, I want to figure out not only to how to have a predictable repeatable, but this should stinking be fun. Like, I would like to enjoy the sunshine and the joy of the day and like people and work with people. So you have tried to figure out how to bring engineering rigor, or at least the opportunity for engineering rigor, to the software development space. At the same time trying to enable opportunities for people to learn and grow and change and experience fulfillment, to your point, suggesting that everyone desires or deserves to be fulfilled along the way. What would you recommend to folks that are just starting their technology journeys? 

0:47:24.1 D Leffingwell: Well, a couple of things. Number one, you gotta be distinctively good at something. Now, one could argue that the framework is very broad and it’s not particularly deep in any area. And that’s probably true. I mean, there’s more written on XP than there is in words in SAFe. But I’m a fan of distinctive competence. I don’t believe that, on average, people hire people that are smarter than other people. And when companies sit around and say, We’re better than them because we’re smarter than them, I don’t believe it. And I ask a slightly different question and say, How are you different from them? Because you can always be different. And in the differences, that’s where the distinctive competency can grow and foster and creates the differentiation you need to succeed in the market. So be good at something and find the thing that you can be good at as a company or as an individual and get really good at that. And then secondly, I think the biggest challenge in my life and personal life and the things I remember, are my mistakes. And I remember them vividly. It’s annoying how vivid the mistakes are. And they’re mostly times when I didn’t conduct myself in a way that I would think any natural leader really should.

0:48:36.7 D Leffingwell: And I have this tough border line between passion, enthusiasm and drive, and being supportive of mistakes and errors and things that don’t go well. And I’ve navigated that well sometimes, sometimes I haven’t. So I remember six or eight times where I absolutely either killed the messenger or I berated someone who was doing absolutely their best job. And I just wish to heck I hadn’t done that. And I kind of remind myself as I go forward to keep the passion and the emotion and the enthusiasm, but to never go too far the other side, that dark side of the really… You gotta be tough to succeed in business, but you don’t ever have to be difficult. And I don’t think that anybody would ever described me as being mean, but, for sure, some people would say, Yeah, he can be difficult. I’d rather be less difficult, so long as it doesn’t compromise the ability to gain consensus and agreement around the things that really matter. So that’s the personal side. The business side, be really great at something. If you’re better, and you can always find a thing that you can be better at. And when you are, you’re going to have special value, and that special value, that’s the leverage, that’s the multiplier.

0:49:58.6 M Edwards: And, Dean, I know that across your journey, discussing the things that you’ve learned and the things that you’ve done, and the highlights and the low lights along the way, that there’s absolutely no way that we can understand value, and honor all of that in just a 60-minute amount of time together. But thank you for taking the time to just talk to us today and teach us and just share with us a little bit about your journey and what you’ve sought to be and become and do, and how you’ve worked to improve, because this is another teachable moment. So thank you.

0:50:36.9 D Leffingwell: Thank you for having that cool XP shop that I learned so much from.


0:50:44.9: The Long Way Around The Barn is brought to you by Trility Consulting, where M Edwards serves as the CEO and president. If you need to find a more simple, reliable path to achieve your desired outcomes, visit

0:51:01.7 M Edwards: To my listeners, thank you for staying with us. I hope you are able to take what you heard today and apply it in your context, so that you’re able to realize the predictable, repeatable outcomes you desire for you, your teams, company and clients. Thank you.


Part VI: How Deconstructing the Agile Manifesto Makes You Better at Barbecue

Show Highlights

In this episode, Derek Lane and Matthew D Edwards deconstruct the final two principles of the Agile Manifesto to help software developers and engineers bring more value to clients but also, become better barbecue pitmasters.

Read the Transcript

0:00:00.0 M Edwards: Welcome back. Today, Derek Lane and I continue our conversation mapping the Agile Manifesto and its 12 principles to making better barbecue. In this episode, we cover the final two principles.

0:00:15.0 D Lane: I think what I’ve learned in the process with the Agile Manifesto over a couple of decades is that, it’s actually the reverse. When you first read it, it’s an introduction to a set of things that if you choose to pursue this in order to understand it, it will not only take you some time, you’re going to have to go back and then wrestle with what you thought you understood before.


0:00:44.7 M Edwards: Welcome to The Long Way Around the Barn, where we discuss many of today’s technology adoption and transformation challenges and explore varied ways to get to your desired outcomes. There’s usually more than one way to achieve your goals. Sometimes, the path is simple, sometimes the path is long, expensive, complicated, and/or painful. In this podcast, we explore options and recommended courses of action to get you to where you’re going now.

0:01:36.9 M Edwards: Alright, so we’ve covered a lot of ground so far, and I suspect that’s one of the challenges that people may have with reading the manifesto and the associative principles is there is just meat in every phrase or segment of these sentences, like this actually takes a while to sit down, dissect or deconstruct to understand, or to figure out how you apply it in your life, how to go live it. This is an amazingly heavy piece of material or set of material for people to think through and apply. I love it, and I love the fact that we’re walking through it.

0:02:12.7 D Lane: I would agree. It’s accidental in that people are unaware that it is actually the process. I think one of the benefits, we have this perception that a manifesto is a declaration upfront, and that if we just read it, we will immediately grasp everything that was intended by whoever put the manifesto together. And I think what I’ve learned in the process with the Agile Manifesto over a couple of decades is that it’s actually the reverse. When you first read it, it’s an introduction to a set of things that if you choose to pursue this in order to understand it, it will not only take you some time, but periodically you’re going to have to follow as we’ll talk about with principal number 12. You’re going to have to go back and then wrestle with what you thought you understood before. It didn’t go far enough, it didn’t go wide enough, it didn’t go deep enough as it needed to once you went a little further.

0:03:20.5 D Lane: And I think one of the real values of the manifesto is after folks have, I’ll say, five or more years of actually being embedded in a natural environment and really struggling through trying to learn agility, that’s when I feel like that’s a real milestone for them to come back and tease this apart and try to break it down word for word, and put it back together in the way that they currently understand agility and see what insights they’ve been able to learn by trying to apply this because it’s in the application that we understand the theory, which is kind of ironic because we believe we understand the theory just by reading it, but we really don’t. It’s only in the application that I think we extract, not only the intent of the writers of the manifesto, but the benefits that they themselves may have not learned yet, they themselves may have not originally intended, seven years later they may have come across it, but they didn’t go back and change the manifesto.

0:04:34.1 D Lane: That’s one of the things I point out in the 20-day Agility challenge is that this is still version 1.0. This hasn’t changed since February approximately of 2001. My understanding is the principles came a little bit later from the first page that we tend to call the manifesto. 

0:05:01.3 M Edwards: Well, I think the co-location of these folks, these folks coming together and working on this and realizing the words and the structures and the intent and the direction is illustrated in this 11th principle. The best architectures, requirements, and designs emerge from self-organizing teams. I would think the development of the manifesto and the principles themselves are good examples of, this team came together and the designs emerged, the architecture, all of the work emerged from the self-organizing team.

0:05:39.0 D Lane: Well, I think your observation is really insightful. The fact that there’s a bit of recursiveness here, that you took people from an extreme programming background, from a Scrum background, from a feature-driven development background, from an adaptive background in James Highsmith and other approaches. And a cross-section of skillsets, and that they weren’t all just coders overcoming from the same type of role and exposure, and when these so-called lightweight methodologies were at that point in their development, these guys got together as happens from time to time, and conferences of folks who are like-minded people, and when they decided to put together this particular meeting at the Snowbird, Utah, that’s when they were able to then make yet another iteration, incorporating a lot of the things that they have learned. And as I’ve heard it talked about from the folks who were there, the first of a three-day conference, the first two days or so, it was a lot of non-getting along. And we’re thinking all these folks, everything was just happy-go-lucky the whole time. And evidently, it was a lot of debate and discovery. But it was the emergence, and this is the principle of emergence that we find in the manifesto.

0:07:05.5 D Lane: The emergence of the pattern of, we value this over this, we value this over this, that was able to be extracted from a lot of what they had talked about in order to find a structure for common ground. And then they could begin to organize around that. I think this principle of emergence is, again, as we talked about earlier, with best practices, it exposes the fallacy of this idea of best practices, it’s just the best thing I know right now when I try to set that as the bar from now on, or for the next five years, if that I’m actually hurting myself. I’m discouraging innovation. I’m discouraging growth. I’m discouraging learning because we all have to do it according to a “best practice”. When this principle demonstrates that in order for us to really find out what the best practice is, it has to emerge from the application of what we’re trying to do. So in the context of software, that tends to be a software architecture. Again, when this came out in 2001, big business requirements documents were all the rage, it was cool, everybody was doing it. So requirements were a very hefty element in the delivery of software. And then we get to designs, and I often hear that, Well, user experience and human-centered design and human factors.

0:08:30.3 D Lane: This wasn’t really around at the time of the creation of the Agile Manifesto. But really, we do have it in here because this was the kind of thing that while there might have not have been an isolated skillset or degree plan or someone who had a title and a role on a project that was focused on user experience or some aspect of that, it really is included in this idea of emergence, in this principle. In that really what we’re saying is the best ideas, the best way to solve problems emerge from self-organizing teams. I think that’s a more abstract variation of this idea. And to me, that gets across this idea of emergence. So we really are looking for the application, we’re looking for iterative value to expose itself or to help us pivot and through that process, better ways of doing things will emerge, which now we’re back to the first page. We’re learning better ways of doing this. Well, how are we learning it? If we already have best practices? We’re learning it because we’re applying it, we’re doing it and we’re helping others do it, and those better ways of doing it are emerging.

0:09:42.0 M Edwards: Now, one of the things that I like about this particular principle, just reflecting on my own journey, is I’ve been in situations in large corporations where there was a designated architecture group and their responsibility was to architect things. And we ended up in situations where we were on the receiving end of all of the architectural thought and direction and plans, and our responsibility was less to question and most to just get it done. And then the architecture ecosystem wasn’t readily available to us because they had moved on to their next project. So we were given a set of deliverables from the architect, if you will, and our job was, “Get it done.” And what I love about this particular principle is, it says, “Hey, we could absolutely have some people somewhere else in the house who have been involved in the business development side of things, the product side of things. They’ve been here 147 years. There are only 148-years-old. They know things.” And it’s very valid. For those folks to be able to say, “Hey, have you considered?” or “You should consider.” Or “These types of things, I’ve had great success with.” But what I love about this is to say, “Hey, even if you are given fences on the pasture, still bringing together the team, the multi-disciplinary team to discover, explore, define, implement, iterate, that’s where the real innovation is happening.”

0:11:21.9 M Edwards: And so when we were bequeathed documents of instruction, there was no innovation, there was implementation following the directions. So I love this as a counterpoint to that. But let me offer this, I like your thoughts on this. I’ve actually heard other people say we are Agile, which in and of itself is not a correct statement. None of us are actually Agile. We’re pursuing becoming more, and we’re using these principles and practices and guidelines and ideas to foster, facilitate, enable, equip, encourage, and so forth. But I am not Agile. I’m actually a blunt force object oftentimes, but I’m not Agile always. But with that logic, I’ve heard someone say, “Because we’re Agile, we don’t actually need to have a roadmap, we don’t have documentation, we don’t have plans, we figure it out as we go.” And that has been received by other company cultures as a cowboy mentality that says, “Hey, you guys can’t tell me how much it’s going to cost, how long it’s going to take, and you’re telling me to just to trust you.”

0:12:30.8 D Lane: Yes, so let’s talk about Barbecue. If I’m going to have any shot at this, it’s not going to be that one. And the reason it’s such a big can of worms is because it is somewhat pervasive, it’s universal, we’re borrowing from this hierarchical thinking that we’ve brought along, and not only how we structure ourselves, but how we organize our plans and our thoughts for how we’re going to execute something. We’ve been taught that we have to do all the thinking up front and all the planning and the designing or whatever that might, requirements, whatever pieces or elements might apply in our domain. And then we’re going to come up… At some point, there’s a process where we identify some cost, and then we have some artifacts, for instance, like what architects might have given you in the scenarios you were talking about. And then there’s a group that’s going to implement it, and then there’s a group that’s going to put it in production, and then there’s another group that’s going to deal with the maintenance and support and the upkeep of it. And the sequential way of thinking is, in and of itself, very anti-Agile, because now we cannot respond to change, outside of the level at which we’re at. If we’re at the design level, we can’t respond to change in budget.

0:13:53.3 D Lane: Well, no, that’s not true, because we know someone’s going to come along with a less of a budget than was already set. You still going to deliver the same amount of stuff or more with less budget in the same amount of time or less. So we know that you do have to respond to change. But it’s always in a negative way, it’s always in, you got to do more with less type of ecosystem. So I think a piece of understanding the intent here and trying to create an environment, as we talked about in number five, that allows people and projects to succeed is that we have to stop thinking in terms of specialization, and we refer to putting people in a box before and then they’re limited to that box. You’re the DBA, you’re only the DBA. I can’t listen to you if you’re going to talk about customer requirements or anything else, because you’re the DBA. Now, we’ll defer to you on the DBA stuff, and we’ve gotta stop doing this, I think now that the teams that have moved to one of two directions, seem to be the most effective at this. One is everybody has the same title. We’re all consultants, we’re all team members, we are all developers, we are all whatever. So we get out of this mindset of, someone with a certain title also having a certain role and responsibility.

0:15:23.8 D Lane: We move away from that to where we’re saying, “We’re all responsible now, and we’re all required to contribute in whatever way our skills and experience and our minds might come up with, again, applying emergence.” That’s one approach. The other approach I’ve seen is everyone makes up their own title. And you can keep that title as long as everybody on your team agrees. So you can’t call yourself The Grand Database Wizard if no one on your team agrees that you’re The Grand Database Wizard. But what you could do is, if I could say, well, and I could get feedback, and again, this is emergence. So we’re coming to a point where we can agree, and now I’m the Grand Poobah of data stuff. Okay, great. Now, at this point, I can avoid being the DBA because I may have a preponderance or a set of training or preference to deal with data, but that doesn’t create this artificial boundary that calling me a DBA does. And so either one of those approaches, and there’s lots that can be done and that I’ve seen done in both approaches is one thing. And what that does is, that moves us to this concept of generalizing specialists. I remember hearing about this years ago from a guy that’s in the industry that I had a lot of respect for. He is one of those guys that always just seems like he’s light-years ahead of everyone else.

0:16:50.3 D Lane: He was introducing this idea, and it was the first time I heard it. This idea that the newer model that we might use it, it would be called the T-shaped person, that’s been around a little, I don’t know, 10 years or so, at least, that we’re no longer just a vertical in our database person, but we also have some experience with other things. We know how to do integration and we know how to do testing, we know how to do some design or architecture, we’re not limited to this one skillset or necessarily constrained in that way. And what I hear leaders say is, “We want more T-shaped people, but then everything they do reinforces the I-shaped person.” The reviews, the titles, the pay scales, the reward system is all based on an I-shaped person. So they’re not doing anything to really encourage the T-shaped behavior, it really just becomes potentially an albatross around someone’s neck, if they really demonstrate that well. So what we’re really looking for is someone who maybe isn’t, no one’s good at everything and no one’s interested in everything, but just make sure that we’re not artificially enclosing someone, and imposing boundaries on them, that may just be where their skillset is right now.

0:18:05.2 D Lane: But I know a lot of people who went to college, got a degree in marketing, got a job in sales, found out that they liked to code and they’re some of the best technologists that I’ve ever worked with. A complete shift of skillset, and they can do the marketing, but guess what? I didn’t even know what this coding thing was, so how would I be interested in that? I think that another piece that we’re missing, when we have the Chief Technology Officer or a set of enterprise architects, and I’ve been parts of all these groups at some point in my career, and they’re going to do all of the thinking up front, and then they’re going to kind of mandate these designs or architectures or tool selections or technology stacks or whatever it might be, it is true that the masses do not have the skillset to make a lot of these decisions. And I would submit, and they never will, as long as the people in the ivory tower continue to hoard, not only the expertise, but the time that they’re allowed to spend on it. If all my time, the opportunity. So what we’re doing is, we’re again, separating this idea, this opportunity to learn, we no longer have shared learning. So if someone comes to the architects and says, We’ve got this problem, can you help us figure out what technologies we should use and we gotta integrate with this legacy system, this third party system?

0:19:29.7 D Lane: Okay, now we’ve got a lot of stuff to track down, it made sense to me that the architects, first of all, as part of a cross-functional team, each one of them should be part of the team, not a team of architects, a team that’s going to go from idea, problem, whatever, all the way to production. Because the other thing that happens, which we all know from a waterfall environment, in the scenario that you described, the architects do something, they hand it off, now they’re on to the next problem or two problems later, they don’t know the impact of their decisions, because they never saw it in production. They never wrestled with getting these two wires to line up. So they lose that learning, again, that shared opportunity for learning. So now we’re back to, let’s talk about a self-organizing team, well, they emerge from self-organizing teams, let’s make sure we have all the skillsets, let’s talk about generalizing specialists so that we’re no longer trying to shoehorn people into a narrower set.

0:20:24.8 D Lane: We’re just saying, I’m a technologist. Right now I’m focusing on this, this is my primary skill to learn, but that’s it. And then we get into the really hard one, which a lot of people say they don’t do, but in our archaeology example, there’s not a lot of evidence that they’re not doing this, and that is the Big Design Up Front. So whether you’re Big Design Up Front is so-called design sprints, which is very popular, Silicon Valley, one or two weeks ahead, where all the UX folks, again, just like the architects are isolated from the teams, they’re going to make all of the decisions about the touch-feely stuff for some system and then they’re going to hand it off, or the architects or whoever, it doesn’t matter what the skillset is, those skillsets need to be embedded into the people who are doing the development, who are doing the design, who are doing the delivery, who are doing the support so that the learning curve is complete. The shared learning is across all skillsets, and now we’re getting back to the original principle, the best architectures emerge. They don’t emerge from the architecture group, they emerge from production.

0:21:29.6 M Edwards: If you take that idea and you go and some people use user stories, the idea of a user story that could be an Epic, which is a theme, it’s a big rock, and that’s broken down on the user stories, which are different types of users, and their stories. And their acceptance criteria at the end of that basically says, this person should be able to do this, this person shouldn’t be able to do this, the use of the system, character is just da-da-da-da. We’re not talking about this here with any great depth, but another set of good books that’s really great for reference, so the books written by Mike Cohn on user stories, user story applied, estimating, etcetera. And you know, one of the interesting things about the approach that he posits in that material is similar to what we’re already discussing. The team is multi-disciplinarian, in other words, those people who sit down and say, This is the EPIC, these are the stories. How they’re deconstructing the stories, and these stories deconstruct into these acceptance criteria, those people all represent the different stripes or ideas in this poly-culture, which is information security, data, analytics, software development, tools, tool change, delivery pipelines, all that stuff, all these things come together as one team.

0:22:46.1 M Edwards: So the best architectures requirements and designs emerge from self-organizing teams, and those self-organizing teams actually assume a polyculture, not a monoculture. And I think that’s one of the important things we’re talking about and differentiating here as well, which is, if I have the tribe of architects, it’s still a monoculture, but if I have a self-emerging team, a self-solving team that includes an architect-type thinker plus, plus, plus, now I have a polyculture. I have a higher probability of capturing a rich environment to deliver customer delight.

0:23:24.5 D Lane: But I think a lot of companies have gotten too busy following the approach that you outlined, where we’ve got specialists and they just hand it down the assembly line to someone else, and it loses that essence, the thing that makes it unique, the properties that allow the customer to be delighted in that unique way. I think a lot of that, it gets squeezed out of the process because there’s no way it can be handed down from the first group to the second group because there’s no one in the second group who experienced it with the first group. There’s no one in the 10th group who experienced anything from the previous nine groups. So, the process itself strangles the essence of learning that occurred at any point before it. No matter how it was documented, no matter how many help videos were created, it’s not the same. And I’ve run this experiment many times in coaching and training where we’ll have two different teams and they’re roughly comparable in most ways that we’re trying to measure in some way. And one team, we will do very much as everybody learns at the same speed, everybody learns, we’re going to slow down if we need to. The other team will be very much, we’re going to try to be agile, we’re going to do some stuff, but we’re going to be order taker, the architects are going to give us this, the product owner is going to give us this, and we’ll just do our piece and then we’ll hand it to the testers.

0:24:58.8 D Lane: And it is undeniable that the second group that follows that very much well-worn, well-understood approach, they’re going to appear to be faster at the beginning because the delta in what they’re doing versus what they’ve always done is very small. So their need to adapt to change is very, very small. Where the other folks are going to appear to be just completely losing it. Yeah, I mean, they’re not even the tortoise, the tortoise is running circles on them because they appear to be going so slow, but there will be multiple times at which they will not only leapfrog ahead, they will time travel. They will move ahead at a pace that is unpredictable because it will stutter a little bit. It’s not a constant pace, but what is constant is that they’re always moving forward. They’re always benefiting from this idea of a shared learning experience, and emergence. The best ideas are coming from this group who is now not just shared a problem to solve, but they have shared the experience and the journey for however long they’ve been able to be on it. And those are the teams everybody wants to be, on after the fact, because they’re like, they can tell these guys care, they have fun, it means something to them. They got everything, I mean, everything that you would want in a group, a working group that people that you care about.

0:26:29.0 M Edwards: I think that’s a really good segue to the last principle on the list. And I’d like to open it up by just talking about this. When I decided I wanted to get into ranching, I believed it was about the cattle. And a couple of old gents that talked to me, looked at me like, you’re fun. They looked at me and I know that they were saying, bless his heart, because how I was corrected as they said, No, sir, you are in the business of farming micro-organisms, microbes, in other words, you are a soil farmer. Because without soil, there is no grass, and without a diversified ecosystem of grass, there is no cattle, and without good healthy cattle, there is no revenue, so you might as well pick a different career. And so, I believed it was about the cattle, and they told me it was about the soil. Similarly, with this Manifesto and these principles, I believe that we’re actually talking about growing people, not delivering software. Everything about this is growing people. And to your point earlier, your team only becomes as great as you enable them to become. I mean, first of all, you have to hire people with great attitudes, great aptitudes. The type of people that sit on the bump of the chair or stand the whole time, and they can’t wait to get into it, so you have to hire those types of people.

0:27:51.6 M Edwards: But when you bring them together and say, You are a team, we need to be a team, let’s go party and just rock and roll on this stuff, they’re only going to become as great as you enable them to become great. So if you only let one person do the thinking and everybody else just has to obey, that’s not a team, that’s not growing a team, and obviously, in that other illustration, that’s not going to be healthy soil and therefore not good cattle and so on. But if you want to grow a team, to your point where it may look like they’re starting off really, really super slow, slower than a tortoise, but at some point, they’re going to time travel, this conversation is about growing people, not delivering software. Delivering software just happens to be the thing. But if we take all these ideas and apply them to any industry, software also, it’s 100% about growing thoughtful people who are working together to rock and roll. So, at regular intervals, in this last principle, at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. I love that. We’re basically saying, We’re giving people the opportunity to think, talk, see, recommend or observe and change.

0:29:15.0 M Edwards: And an interesting thing is, it has to be an environment where they know they have permission or they need to be able to say, these were amazing activities, amazing results, super happy to be here, let’s do this 47 more times ’til it doesn’t make sense. But at regular intervals, whatever that is, the team needs to be given permission to think and decide and evolve together, ’cause we’re in the business of growing people.

0:29:40.9 D Lane: Well, again, I think that’s a great observation. I think that that really gets to the essence of the first page of the manifesto is, it really is about people. And the way I kind of over-generalize in a nutshell, you know, kind of the 10 words or less, what is agile? What is agility? To me, it’s this idea that we have this relentless pursuit. For a long time, it was just the pursuit of value, but I think it’s the relentless pursuit of value. And I think it’s the idea that we constantly have people who are engaged in a positive way, and I think that’s what you’re describing, is people who want to be here, is people who want to continue on this journey, is people who feel safe to be able to raise their hand because they don’t understand something that everyone else seems to understand, as well as people who are just questioning what appears to be the prevailing thinking. We’ve been doing this for a little while, we’ve kind of been going down this path, how are we going to deal with X? I haven’t heard anybody deal with X, and I’m the new guy here, and I don’t know anything about it, but I really don’t understand, is it just me?

0:30:49.4 D Lane: And I think a huge aspect of that is knowing that it’s safe to do so, but doing so in a way that is constructive and not accusatory. We need to remove this idea that we have to judge everybody’s idea, and we have to remove this marriage that we impose on. If someone says something, it’s their opinion, it’s their idea, and we dislike it, then we respond in a way that indicates we dislike them. We have to remove this idea, and I think that’s really where we get to the true cross-functional team. Because of all of this, none of this happens without trust. The way that the team members get to that point of safety is that I know I can trust you. If I’ve got a delicate conversation, I’m not going to go to people I may know really well or have known for decades, I’m going to go to someone I trust, someone I trust that’s not going to reveal the confidence, that’s going to give me sound advice, someone that may not have any answers, but I know I can trust them to be on my side.

0:31:55.2 D Lane: And if they need to tell me something that’s for my own good because I can’t see it, I not only value them in order to have that conversation, but I’m willing to listen to them because I know that they’re doing this for me. They’re not just doing this for them, or because they don’t have the time or any of the other things, they’re actually taking me into consideration and trying to figure out, what’s the best thing I can do to help him at this point, and based on the conversation of the topic or whatever it is that’s going on? I think those are critical elements of having a successful team, period. And then when we add in the self-organized and the cross-functional, those are other characteristics of, again, successful, high-performing teams. Not just teams, these are the teams that everybody wants. These are the teams everybody wants to be on. And so, absolutely, I think the reflection or this iterative cycle of how do we get better, if anything, this 12th principle represents for me that the Agile Manifesto has incorporated in it within its structure, the requirement in order to achieve agility, you are required to create a learning environment, a learning culture. It is not possible for you to maintain agility without it.

0:33:14.8 D Lane: So a lot of the things we’ve talked about are things that stifle the ability to be agility, the ability to innovate, the ability to have a safe environment to say, I think we’re about to drive off the road. Is that what we want to do? Because someone else higher up the food chain is beating their chest or screaming or pounding their fists or whatever else they might be doing, which creates that environment that says, Okay, obviously, I’m the newest guy on the totem pole, there’s no way they’re going to listen to me. When in reality, the fact that I’m the new guy gives me a unique perspective and that should be valued by everyone else on the team. They should realize I don’t see things the way they do yet, and I can help them see some of their blind spots. I can help them see some of the weaknesses that they’ve been looking at it so long that they aren’t aware of it. I know I do that all the time. I try to make sure people see things before I kind of make them available to the masses. That doesn’t mean any of us will catch everything, but I’m trying to increase that value for everybody.

0:34:21.6 M Edwards: Well, let me unpack that just a little bit. When we’re talking about psychological safety for people who may or may not be familiar with that word combination, we’re not talking about padded rooms where nobody is ever going to say something that might hurt your feelings. We’re not talking about spaces where people don’t really say what they’re thinking for fear of offending someone else. Every human and every human on these teams has a responsibility to understand and communicate. And oftentimes that happens with questions, by asking questions like, What do you think about? Have you considered? What would happen if? What are our other options? Just questions that stimulate ongoing evolution, that fosters an environment of learning. A psychologically safe environment doesn’t mean we aren’t transparent with each other and direct and communicative, it does suggest that we honor and respect each other, which is, Derek, the thing that you just said, internally, all my lights are going off and I’m thinking that’s one of the craziest things I’ve ever heard good, sir. It’s possible, I don’t understand it. It’s possible, I completely missed the bus. It’s not making sense to me. Could you re-explain it in a different way, I’m being dense?

0:35:43.1 M Edwards: That’s a non-threatening way for me to say, dude, I think you’re saying crazy things, but I realize that I could also be the hoser here. So, let’s go a second at-bat here. There’s got to be an environment that fosters, encourages, enables, invites the opportunity to learn, and learning happens with questions. Declarative statements like this one shut conversations down. This is all about people all day, every day, all of the time, and until we figure out how to grow and enable and equip and educate and love people, you may or may not deliver whatever it is that you deliver software included.

0:36:25.4 D Lane: Completely agree. The thing that a lot of folks are confused about the Agile Manifesto, especially when they see it from the standpoint of software technology, developing a technical product, there’s nothing in here about version control or about what programming language to pick? Or do you need a client-server architecture, should you be using the cloud? Where does mobile fit? None of these things are here, much less higher-order things like, how reactive does your system need to be, how do you scale it, how do you deal with internationalization, how do you deal with security? There are really complex elements of good designs, good software products, services, architectures, how do you deal with all of that? It’s not here. It doesn’t tell me what to do. No, it doesn’t, because as you have so eloquently pointed out, almost all of these have to do with the people, they have to deal directly with how as a group, in order for us to come close to dealing with the complexity of the technology and the problems we’re solving with, we have to create an environment in which it’s safe for us to be ourselves, it’s safe for us to grow and learn, it’s safe for us to make a mistake, it’s safe for us to be able to share with somebody to say, You know what? That doesn’t make sense to me. I don’t like it. It feels funny. Is there a better option? Is there something else we could do?

0:37:57.5 D Lane: And it’s perfectly acceptable to say, You know what? It’s not that I disagree with you, but based on delivering for our client, I think given the short timeframe, we could still deliver something here, and then we could come back and address that in the future thing. And that’s perfectly okay. But the thing that rarely happens in the real world is that if we get that agreement and then we release it, we never come back to the thing and fix it. We not only have the technical debt, which folks nowadays at least, most of them have heard that expression, we now have people debt, we have debt that we have damaged our ability to trust, whether it’s someone inside the team or outside the team. Now we’re back to principal number six. The most effective and efficient way to communicate, because I don’t have to communicate with you face-to-face, I can make this decision unilaterally and it’s going to affect you, we’re not going to deal with that anymore, it’s not a high priority on my backlog. So if you guys can’t deal with it, tough, I’ll get some other guys who can.

0:39:00.9 D Lane: This is not a psychologically safe environment, this is not a learning environment, this is not about an environment that values people and interactions over processes and tools. Now we’re archaeologists again and we go say, where is the evidence of agility? The fact that we might be having stand-ups five times a day, or that we’re tracking things with user stories, these are all practices, they’re all optional. None of those are required for agility, they’re all just a mechanism, a means to communicate, a means to value ideas and to represent customer value or team value or organizational value, and a way for us to begin to try to figure out how do we communicate and share that information. I think that’s a big difference in how most people read the actual manifesto, they’re looking at it as the decrypt software development forum, it’s decrypting it, but not the part that they’re thinking.

0:40:01.1 M Edwards: So the best architectures, requirements of designs come from a self-organizing team is basically what it’s saying, and at regular intervals, that self-organizing team takes time to reflect and learn and change. Now, how do you see that happening in barbecue? What does that look like when you’re barbecuing?

0:40:20.1 D Lane: So I think the idea of a self-organizing team in barbecue is very apparent when we watch some of these TV shows, whether it’s public television cable channels or Netflix or whatever, and you watch a competition, and I don’t mean a competition with Myron Mixon or some of these guys who are world famous and have been for decades, I’m talking about the guy and his wife and the brother-in-law and the cousins who are on the barbecue team who are trying to compete, they’re going to be given a set of problems that they’re not expecting, now they’re ready for a lot of stuff and they practice, they’ve done what they could, but again, they don’t have any control over the weather, they may not have as much control over the fire as they think they do, the expectations of the judges may change the day of the event, they may be given some rules that they weren’t planning on, so now they’ve got to come up with, Well, now we have to make something that we weren’t planning on, Well, we didn’t bring a recipe for that, so the idea of the self-organizing team, Okay, well, what do you think? Well, I don’t know, we got this or this, we can make pork chops or we can make stew. Well, okay, I don’t know which one.

0:41:36.9 D Lane: So now we get to the point of, It’s not just reacting, is how much do I trust the other people on the team? I know that Matthew is really good at things that are of this type of nature or these types of seasonings, if we have ingredients that fit that profile, I might want to defer just because I will be able to trust him, and know he’s going to build something that’s going to be great, it may not win, but it will be great regardless, and that’s this idea of the self-organizing, the trust, and in barbecue like I said, it’s the most apparent there. Now, for folks that are at home, backyard, barbecue guys like me, I think that this becomes real apparent in just some examples that we’ve already given, like how much fat should I trim off of brisket? Well, there were some requirements that there was designed that people said that they had success with, and I tried those, it turned out that it’s not that they worked or didn’t work, necessarily, I can rank them on how much success I had, but if I found a better way of doing it, if it emerged through experience and practice and it was a better method for me, well, that’s why it emerged, I didn’t limit myself to saying, Well, this is the requirement, somebody else did all the design thinking up front, and so I’m just going to follow their instructions.

0:43:00.6 D Lane: It’s great as a starting point. And I definitely would warn people against starting out doing their own thing before you’ve learned how to follow some other people who’ve been before you, that’s going to slow you down quite a bit if you don’t, but I think that’s part of the learning curve, and that’s why we have things like Scrum, that’s why we have extreme programming, those are people who’ve gone before you, this is a starting blueprint, but the way that I often try to reset people’s expectations is they think, well we’ve been doing Scrum for six months, we’re experts at it and all that, and I said, Well, first of all, you understand, you should always do Scrum out of the box if you’ve never done it before until you start making changes. Second of all, you understand Scrum is for kindergarteners, this is the beginning entry point, this is not the master level, no that masters can’t use Scrum. That’s not what I said. Listen to what I said, I said, it’s the beginning point, it’s the entry point, this is the training wheels.

0:43:58.9 M Edwards: Excellent way to start.

0:44:00.1 D Lane: It’s a great way to start, and XP is a great way to start. And all I’m saying is that I think it’s definitely people-centric for barbecue, it’s people-centric, and I think you can apply a lot of these same things, you can apply a lot of the techniques, you can write user stories for your barbecue recipes, you can create a Kanban board for everything that’s going to go on the pit and keep track of, is it on the pit, is it off the pit, where is it at? There’s a lot of these things that will translate the different building blocks that you have, so principal 11, I think the best things emerge and they emerge with what you’re comfortable with, what you gain proficiency with, I think for principal number 12, after every cook, after every barbecue contest, you have to have a retrospective, you have to go back and say, Okay, what did we do, what happened? Why did we make those reactions, how did we recover? Did we think we did well? Was there a better way? Was there something that we knew about that we could have done that we just, didn’t occur to us, and if so, how can we make that more evident next time? So I think that that happens whether you’re part of the contest, or again, you’re just doing ribs in your backyard.

[barbecue sizzle]

0:45:13.2 M Edwards: So let me just bring it all the way back around to how we started this conversation, which was around the Manifesto in and of itself, while there is value in the items on the right, we value the items on the left more. Now, you could argue that that’s a declarative statement, but that’s not how I read it. How I read it is, Hey, we favor these practices, these principles, these tenants, these behaviors, that doesn’t mean there aren’t others, but these are the ones that we have found enable the greatest number of value-based ripples in the journey, and so I love that as the bookend to this whole conversation, because they basically said, Hey, here are the things that we have seen, here are the things that we think, here are the things that we favor and believe and suggest and recommend, and would love to talk to you about it. Now, we’re going to drill down harder on it with the principles as well. There’s value in the items on the right, so they didn’t make any declarative statement that says, You must not. You shall not. This should never happen. It wasn’t a set of negative statements, it was a set of positive statements that says, this can work and this can work, however, we favor this one over here because we feel like the results are richer, there’s a greater value proposition in the things on the left.

0:46:43.5 M Edwards: So I love the fact that it’s a positive set of statements, we favor this, this can work also. We favor this. Because they could have gone completely negative on it, which is to say, anything that has come before us is stupid, anything that’s contrary to what we document is also stupid, if there are new versions of this in the future, that’s stupid. This will stand the test of times forever, and that would be completely counter-intuitive or even antithetical to its entire point of existence, which is: learn, change, become. And to your point earlier, this doesn’t have a darn thing to do with tools or any codey things or any technical things, it’s about people everywhere in all of the directions.

0:47:33.0 D Lane: And so, one of the things we talked about early on in this conversation was the learning that I had come across that originally, or initially in my career, once I was introduced to technology and building technology, that when you try to build something, you try to figure out what the problem is, that people were about 10% of the problem and technology is about 90% of the problem, and with the caveat that, Yes, technology has grown tremendously, and we’ve got a lot more options available today than we did back into the dinosaur days that I’m initially referring to, but through that time, I’ve come to know or revise my thinking to believe that technology is now a 5-10% of the equation, and people are really 90-95% of the equation. And so when we’re dealing with people, and we realize this is really about people, and we realize that while there is value to the items on the right, as you said, it doesn’t mean there’s no value, there is value, we’re making that declaration, but we value the items on the left more, and why do we value them? Because of the first part of the manifesto and because of the principles that are how we illustrate that.

0:48:51.6 D Lane: I saw a quote recently that I thought it’s not attributed to anybody, so I’m not sure who originally said it, but I thought it was a great synopsis really of agility, and that is our responsibility in responding to change is to adapt. So to me, the thinking here is, the reason people focus on tools, the reason people don’t focus on people is because: tools are easy, people are hard. We don’t want to solve the hard problem, we want to show progress, we want to fill up the queue with busyness. And one of the things that I’ve learned is to never mistake activity or busyness for results. Lots of organizations are filled with activity, they’ve got busyness all over the place, nobody can ever get to everything on the list that they’re given, and they contribute to that list themselves, because of the other things, the constraints, the environment, the reward system, but now we’re back to wearing our archeologist hat, is there evidence of agility, is there a continuous frequent delivery of value with customer feedback to help us pivot or persist? And if there’s not, then we may not…

0:50:20.1 D Lane: When we’re back to executives wondering, Hey, we’re spending a lot of money training and making this change, is this really worth it? The answer may be no, you’re not getting the value you should be getting nor are you getting the value of you have potential because the environment you’ve created has shut people down, you’ve copied and pasted your previous organizational chart, and just renamed everybody that was a Project Manager to a Scrum Master, and the infinite number of anti-patterns that you and I have seen about things not to do, how many volumes of books could we write of these are things not to do? This is almost guaranteed to constrain, if not completely kill agility.

0:51:01.5 M Edwards: I have absolutely enjoyed this conversation, walking through the Manifesto, walking through the principles, and in particular, I have a few times in my life been more hungry [chuckle] than when we have paralleled these things to barbecue. But it makes absolute sense to me that if you don’t want to talk about software, let’s talk about barbecue and you can absolutely apply this Agile software development manifesto from top to bottom to a barbecue journey, every word in these sentences can be applied to barbecue, and I love it.

0:51:38.1 D Lane: Well, as I said, I’ve been looking to do this for a while, I really appreciate you pointing my brain and my conversation in this direction and helping me be able to focus on it for a little while. Thanks very much.

0:51:51.5 M Edwards: Thank you for listening. This is the final episode of the series with D Lane and the intersection of barbecue and the Agile Manifesto.


Part V: How Deconstructing the Agile Manifesto Makes You Better at Barbecue

Show Highlights

In this episode, Derek Lane and Matthew D Edwards deconstruct principles 7-10 of the Agile Manifesto to help software developers and engineers bring more value to clients but also, become better barbecue pitmasters.

Read the Transcript

0:00:00.0 M Edwards: My guest, Derek Lane, and I continue our conversation mapping the Agile Manifesto, and its 12 principles to making better barbecue. In this episode, we cover principles seven to 10, and I recommend staying until the end because Derek shares how to keep things simple in order to make amazing brisket.

0:00:24.2 D Lane: It’s the pursuit, the constant, never-ending pursuit of value and value as defined by the customer. Now we’re back to number one, it’s to make the customer happy, to satisfy the customer’s goals. Is that to increase business? Is it to move into a new market? Is it to experiment with the product? Is it to reduce cost or reduce expenses? Is it to reduce the number of people it takes to maintain some part of their business? Is it to get the best barbecue that you can get this side of the Mississippi, whichever side you’re on?


0:01:07.5 M Edwards: Welcome to the Long Way Around the Barn, where we discuss many of today’s technology adoption and transformation challenges and explore varied ways to get to your desired outcomes. There’s usually more than one way to achieve your goals, sometimes the path is simple, sometimes the path is long, expensive, complicated, and or painful. In this podcast, we explore options and recommended courses of action to get you to where you’re going now.

0:01:39.1 Speaker 3: The Long Way Around the Barn is brought to you by Trility Consulting. For those wanting to defend or extend their market share, Trility simplifies, automates, and secures your world your way. Learn how you can experience reliable delivery results at

0:02:00.9 M Edwards: The next one of these principles, working software, is the primary measure of progress. I love it, I love it, I love it. It kinda harkens back to the, “We prefer working software over documentation,” or even my original commentary, which is, “Hey, man, there’s a time and a place to show up with a PowerPoint or a Word doc or whatever it is that you’re generating, but the reality is that if you’re a technologist and the client hired you to deliver some technology, they want to see technology.”

0:02:32.9 D Lane: Again, if we abstract this a little bit, it’s value. Whatever the value is, is the primary measure progress, the delivery of value, okay? How much better are you at delivering value? We’re spending hundreds of thousands of dollars to have consultants come in, or we’ve hired extra agile experts. How do we know if it’s making a difference? How do we know if we’re getting better? The delivery of value is how we measure progress.

0:03:09.4 M Edwards: I like that question you asked, “So you’ve adopted X, are you delivering more value than you were?” That’s really the conversation.

0:03:18.1 D Lane: Exactly. For me, if it’s possible, and it’s really hard because there’s so many facets to what is agility. How do we know if agility is occurring? Or is possible? Or is improving? So that at any point in time, we have the ability to adapt. So how do we know? It’s the never-ending pursuit of value and value as defined by the customer. Now we’re back to number one, it’s to make the customer happy, to satisfy the customer’s goals. Is that to increase business? Is it to move into a new market? Is it to experiment with the product? Is it to reduce cost or reduce expenses? Is it to reduce the number of people it takes to maintain some part of their business? Is it to get the best barbecue that you can get this side of the Mississippi, whichever side you’re on? Whatever the pursuit of value is, to me, is the closest to a nutshell that I can put agility in. And in this case, how do we know if everything we’re doing, whatever that is, is making us better? The way we measure progress with agility is by delivering value.

0:04:37.4 M Edwards: So I’m standing beside you, we’ve been smoking this brisket for quite a while. I’m able to stand beside you when you lift the lid if and when you open the box. I’m able to stand beside you as you’re putting more wood in. I’m able to stand beside you as you succumb to the temptation, or to my persuasion to just let me cut into it just a little bit and taste it. But the reality is, I’m there beside you, we’re journeying together, and I know things are happening but I’m even more incited to continue on this journey with you. If you act like you didn’t notice that I took a little piece off that brisket when you turned around, or if you said, “Hey, I know it’s not quite ready yet, but let me give you just a little sneak peek of the sauce or the rub that I used.”

0:05:27.4 D Lane: Yes. And if you’re the customer, imagine how different whatever we call a project would be, if we have that customer going through the same experience with the team that is developing and delivering that value. Because now the level of communication, the level of transparency, the level of trust… You get to see, you know the effort I put into it, you know the decisions I’ve made, if we’ve had a discussion, you know pretty much why I did everything I did to the degree that you were interested or it made sense. And barbecue, in this case, is no different. It’s great to go to whatever your local barbecue place is, go on a day or a period of time when they’re not busy, call ahead if you want to. Ask if you can go in the back and see their pits, ask if you can talk to the pitmaster. You can just learn about what kind of wood they use or what their technique is. That gives you a different view, a different experience, a better appreciation for the value that you show up and get as a customer. You just get in line or you order from the menu and it magically shows up, that’s the way most people want to order their technology and their products, but the reality is that it rarely gets them what they want. It’s like ordering a very specific order, but what shows up is not really what you ordered.

0:07:01.1 M Edwards: And that’s where I have heard someone characterize in Past Lives that it’s fine to deliver as committed and the customer or the client may say, “You’ve done well, good job, thank you for your time.” But an exceptional experience for the class customer is when they are delighted, when they are beside themselves with happiness, because you not only did what you said you would do, but you delivered a version of that and or more. That helped them realize their goals quicker or differently or more evaluably. Working software is the primary measure of progress as it relates to the technology, but it still, to your point, rolls up to satisfy the customer and satisfy isn’t just, “Here’s brisket.” It’s, “Here’s brisket that you’ve now canceled the rest of your afternoon so you can just marinate, soak and enjoy the meat sweats that go with it.”

0:07:57.7 D Lane: That’s really I think what is intended by “satisfy the customer.” It’s the level that Simon Sinek talks about when he says that everybody needs to understand their why, the golden why. The idea, people don’t care about what you do, they care about why you do it, and that is very true with barbecue, but I think it’s evident in this particular principle. You said something else that I think is very much buried in this, it’s taken me years to try to find a way to talk about it. And that is that we often talk about backlogs and effort, level of effort, and, “When will I get to see something?” And, “When will things be done?” And we talk about commitment in that context. From my standpoint, I feel like one of the light bulbs that demonstrated that I got it, that I really was beginning to understand what agility is, is when I understand… When I began to understand committing to a backlog is wrong, it’s incorrect, it’s making… It’s efficiency in the same sense that we’ve always been doing projects, in a waterfall sense, it’s traditional that has carried over even into the agile space, and we haven’t realized it. We’re still polluted with these concepts, and it affects what we do and how we do it.

0:09:27.0 D Lane: Instead, I would submit that we should agree to be committed to the values and principles of the Agile Manifesto. I think if we’re committed to those and we agree that the decisions we make and the behavior that we subscribe to will illustrate and demonstrate the values and principles, we can trace it directly back to that. And the illustration that I use for a lot of teams is, if we were an archeologist and we were looking for evidence of agility in your company, would we find it? Would we find hieroglyphics that demonstrate that agility might have been here? Would we find frequent delivery of value? How frequent? What does that frequency mean in the context of whatever the value is you’re delivering? Would we find dinosaur tracks? Would we find fossils? Would we find evidence of agility? So whether it’s Lean or Agile or human-centered design, would we find evidence of that? And by evidence, I don’t mean burndown charts, I don’t mean sticky notes on a whiteboard, I’m talking about the kind of evidence that says… Not that says, “We were doing practices,” because you and I both know we’ve seen those things as evidence in environments where agility did not live. So that’s not evidence of agility, sticky notes on a whiteboard and burndown charts, burnup charts, whatever, that’s not evidence of agility, that’s evidence of a practice, or that’s evidence that someone thought this needed to be created and it was left behind.

0:11:12.7 D Lane: So what is evidence of agility? Evidence of agility is a group of people who trust each other, that’s evidence of agility. Now back to principle number five, let’s create an environment, let’s invite people who are motivated into that environment, let’s explain to them what our problem is, let’s trust them to do it. So there’s lots of things that are evidence of agility. And I think that the way we achieve that is to not commit to a set of backlog, a set of things in a backlog that is going to change and that should change as we learn more. If we assume that, then we realized, “Well, that’s really not a good thing to commit to, it’s too fluid. We should instead commit to the values and principles of the Agile Manifesto. If we do that, first of all, they’re not as fluid. Second of all, the deeper we understand them, the better we can apply them. And third, it becomes a common shared baseline ruler that we can all use and talk about how we can improve it? And how are we interpreting it? And are we applying it in a consistent way?”

0:12:28.1 M Edwards: So the net still is working product.

0:12:31.5 D Lane: Yes. The measure of progress is a working product, evidence of agility is the elements that allowed you to create a working product. So it’s the frequency of delivery, it’s the delivery of value on a regular basis, it’s the delighted customer, that’s evidence. The measure progress… So we can make progress while we’re still on our way, right? We’re going to drive from where we are to the other end of the country, we can make progress without getting to the end. We don’t have to wait until we get to the end to say, “Did we make progress?”

0:13:14.6 M Edwards: So archeological evidence, to some extent, of agility then is additionally articulated in the next principle, the eighth one on this list, which is, “Agile processes promote sustainable development. Explained, that means sponsors, developers and users should be able to maintain a constant pace indefinitely.” The reality of the situation is we’re talking about perhaps some form of psychological safety, we’re talking about a healthy environment, and we’re talking about a team that’s composed of people who are all equally able to say, “This is what I think, this is why,” and they together in the self-organizing teams that are saying together, “We know we’re in a marathon. We know the work that’s in front of us. We are able to adapt to change and invite that as necessary. As such, we’re not going to kill ourselves on this iteration. We’re not going to kill ourselves on the next six iterations, because this could be a 200 iteration project with multiple major release drops along the way that are publicized by the marketing teams and so forth. It’s lasting.” What type of team and people and environment do we need to create in order for people to last?

0:14:40.2 D Lane: The way you described it as the first statement, “Agile processes promote sustainable development,” being explained by the second statement. The sponsors, developers, and users. Well, this is the first time we’ve heard sponsor. Before we heard customer, we heard business and we heard developers. For the first time, we’ve heard sponsor in the sequence of principles. This is where we begin to realize that I can have a customer who could be an end-user and I need to delight them, I can also have a customer, which is the person who’s paying a.k.a. the sponsor to develop or deliver this product. What delights each one of them is not necessarily the same thing. And the more complex the value that you’re delivering, the more likely it is that what makes… That will delight them is not the same thing.

0:15:32.9 D Lane: An end-user for Google is very happy to get fast results, the fact that ads can influence the results means that I may not get what I want, the fact that my history influences the results and they’ve updated their algorithm for that, however that satisfies the desire of Google the company, that’s how they’re making money. They want their ads to be effective, they want the customers of the ads, the people who are paying Google to place the ads to be happy so that they continue to advertise on their platform. So Google, the person, the sponsor paying for the development delivery of products, their goals, what makes them happy, what makes them… What gives them a competitive advantage, is not the same thing as the people who are the end-users. And here we get a little bit of insight into that because we’re talking about the sponsors, the developers and users of that.

0:16:32.0 D Lane: So we realized that the ecosystem of people and the roles they play is broader than we’ve covered so far, you just need to think about those roles and the people, and you need to adapt, which is what agility is, is adapting as you learn more things. I think the next interesting thing about this principle is, remember principal number four, “Business people and developers should work together daily throughout the project.” Where are the business people in this principle? Because the sponsors could be the actual client who’s paying for us, who has end-users. Now we’re back to, “Okay, business people should be part of that development team.” And then of course, end-users are the end-users of that client, the people who buy things from the floors.

0:17:22.7 D Lane: So I think what’s happened here, and it’s a very subtle thing and I didn’t see it for a very long time, is that the authors of the Agile Manifesto did something that we run over so quick, it’s not even a gigantic speed bump, and that is that they went from, “Business and developers should work together daily,” into, “Okay. We assume that’s happening by the time we get to principal A.” And so it’s encapsulated in this idea of developers. And the developers here might not mean just the technologist in the case of software technology, it could be everyone. Now we’re back to our original idea, “Everyone involved in delivering value should be included in that.” So if that’s the marketing department, if that’s HR, if that’s legal, whoever it is, they should be part of that conversation. This means, now we’re back to principle number four, they should work together daily.

0:18:15.3 M Edwards: Right, they’re interwoven. This is a tapestry, these are not single threads that could be practiced alone.

0:18:22.0 D Lane: Absolutely, and that’s how I think most people see these as individual discrete values and principles, when in reality it’s really more of a network graph, every one of them is connected to every other one. So barbecue, how does this relate to barbecue? I think Agile processes promote sustainable development in that it is difficult when we talked about cleaning your pit before, and that you can get debris in the way that can actually get in the way of you delivering a consistent or a good product, at least on a regular basis, if you don’t… If part of your process, your regular process, not necessarily every time you’ve cooked, but if you don’t have something that says Every so often, I’m going to clean out the ashes, I’m going to check for debris, I’m going to wash my meat, we mentioned about that earlier, about… These are consistent things, doing these things.

0:19:22.4 D Lane: How does that… What does that mean with an agile process, how is it related to that? Because it gives us more consistent results, it becomes sustainable, we get to this idea of sustainable pace, which is also embedded in this, to maintain a constant pace indefinitely, the more common phrase we use is sustainable pace, that’s also in the first statement, promote sustainable development is sustainable pace because, in reality, you may need to work more than 40 hours, the intent of 40 hours was to say, Let’s don’t burn people out to the point that they can no longer think when that’s the critical value add that they have, so let’s don’t get them to the exhaustive point, whether you leave the project or with all their domain knowledge and everything else. Let’s stop before then. Let’s make it reasonable. Sometimes it’s going to be 45, maybe it’s going to be 50, maybe sometimes it’ll be more than that, but we should be aiming at something that’s reasonable and sustainable for everyone.

0:20:24.1 M Edwards: That makes sense. So in context of the archeological examples of agility, looking inside some particular culture or sub-culture, that brings us to the next one as well, which is pretty interesting because of the implications, how spiders into the team, the team construct, the team behaviors, the team attitudes, continuous attention to technical excellence, and good design enhances agility. That’s one of my favorite conversations here. Now, from my perspective, this leads to all kinds of things. So continuous delivery pipelines, continuous test, security by design. All kinds of conversations like that. Good design enhances agility. For years and years and years, we’ve had the merits of this architectural behavior over this architectural behavior, or the merits of this design structure, or this design pattern, and so forth, talking about lots of the tools and the toolboxes.

0:21:22.1 M Edwards: My favorite thing out of this though is still a people conversation, I believe this again, points back to people and relationships, continuous attention doesn’t just mean automate all of the things in your infrastructure is a code environment or you continues deployment environment. From my perspective, at the most fundamental level, continuous attention to technical excellence is not only having a group of people that are pursuing mastering their craft, but it’s practices like test-driven development, pairing, pair-switching, mob programming, finding ways to enhance and lift and amplify people, and people together, it’s still organic. It’s still relational, it’s still people. We can add tools, but it’s still people.

0:22:11.5 D Lane: I definitely think that’s a great way to interpret the continuous attention phrase, it’s definitely… People are who we’re talking about, paying continuous attention. I think this exposes… This principle exposes one of the long-held and long-promoted… We’ve always done it that way. It’s a good industry saying, and that is this idea of best practices. To me, that is… It’s severely flawed in a number of ways, the way that it’s often used in most companies, this principle exposes that while you may know the… You may have a level of skill, a pursuit of mastery that you mentioned, I may have a level of proven ability that delivers value in some way, but the point at which I say This is the bar, a.k.a. our expectation, this is our best practice, and we document it and we promote it, and we make sure everybody’s doing it, that is the exact second at which we quit innovating, that’s the exact second in which our agility begins to go down, it’s the exact second in which people will be reprimanded for thinking and trying to make something better.

0:23:34.6 M Edwards: Well, it’s consistent with other behaviors that we sometimes see in companies or teams or projects whereby we say, Well, that person is responsible for the user experience, that person is responsible for regulatory compliance, that person is responsible for data, and a challenge that comes along with those types of designations, similar to what you’re saying, is after it’s stated, it then becomes no one else’s responsibility as their primary thought process, so I tend to favor part of the Idea propagated by Mike Cohen and user stories, user stories applied, estimating all of that is that a user story and its associative acceptance criteria actually reflect all of the personas required in order to deliver that user story, which then is a component of perhaps a larger epic or whatever theme to the light of customer, but inside those acceptance criteria, those things actually reflect all of the rules.

0:24:36.0 M Edwards: And so technically, if we are a team, a self-organizing team and we together, composed of many different roles are responsible for delivering the software, security is everybody’s job in my opinion, user experience is everybody’s job in my opinion, and delivering well is everyone’s job, but one of the ways I’ve liked to mix it up instead of designating, and then you become this thing forever for this particular breakout, Derek, you’re handling user experience, but for the next breakout, you’re handling regulatory compliance. And so it forces everybody out of their behavioral patterns to say, “Well, this is my expertise, I do data, I don’t do user experience, that’s that other person.” Those are interesting conversations to have continuous attention to technical excellence, I think it requires you to think broader than just your personal favorite sweet spot.

0:25:37.8 D Lane: I completely agree, and I think another… In addition to that, which is a huge problem, people get essentially assigned and identified, so what you’ve described, as I heard it, was the assignment of some role or characteristic or responsibility, I think the same thing is also true with regard to the idea of, I introduce Matthew as the data expert on this particular thing, and that means now until forever, you have been put in that box, and that means that I don’t… Not only do you not think about things outside of that, I don’t listen to you about things outside of that, because you’re the data guy, you don’t know squat about user experience or about whatever.

0:26:31.1 D Lane: Well, okay, so I’m devaluing the fact that you are an individual and that we have interactions and that you are a knowledge worker, I am deferring all of those questions to a constrained, limited number of people, and I’m also ignoring some great innovation that I’m not all ignore it, I’m intentionally excluding it from ever happening because we’ve squeezed it out of the process, now we’re back to continuous attention to technical excellence and good design enhances agility. Innovation enhances agility. I think another characteristic here is there’s technical excellence, and then there’s good design, those are not the same thing, they’re discrete things that we’re called out here, I think in barbecue, technical excellence might mean…

0:27:23.0 D Lane: I have good fire management, I understand the mechanics of how a particular pit draws, how to deal with the managing… Not only the fire, but the smoke, I need to manage the heat, I need to… Is there a cold spot? Is there a hot spot? Is there a certain element that I’m going to put on the smoker that even for a short period of time is going to get way too much smoke so that it’s going to ruin the value, my ability to deliver value with that item? There’s a lot of things here that we could talk about that are the technical excellence part, good ingredients make a big difference in just an average set of skills, you can end up with a lot better barbecue if you really get good, and I don’t necessarily mean more expensive, I just mean, you have to… It comes down to quality, not price, but the design is also important, and that’s back to things I’ve talked about, like the order in which you want things to come off the smoker, so that everybody gets to eat everything, everything’s kind of completed at the same time. I have to plan what order to put things on the smoker, everything doesn’t go on at the same time. If I’ve got something that’s going to take eight or 10 or 12 hours, I may have to wait until two hours before that to put something on.

0:28:43.3 D Lane: Cobbler is not going to take that long, so I need to put it on an hour or two hours before, it’ll have more than enough smoke, it’ll be perfectly done, even if everything’s wrong when I put it on there, whatever that might mean. So now we’re getting to the point of both of those are intentional, and I think that’s the continuous attention piece, it’s intentional, only people can do it, you can’t automate it, and it improves our ability to innovate, to come up with ideas, to not constrain ourselves to the way we’ve always done it, not only by putting people in a box, not only by saying this isn’t the best practice, well, how are your best practice is ever going to get any better if they can only be best… Whatever your current idea of a best practice is.

0:29:24.2 M Edwards: I love that call out, the call out basically, you led with was once I define a set of best practices, it often leads people to stop innovating, so if I say this is the line, all projects hereafter need to have these 10 characteristics, these behaviors, these toolchains, whatever, whatever the definition of the spec is, this is the best practice. People will spend all of their timeline following and not as much time figuring out how to add context-driven value for the client. I think that’s also a really good amplification of why the manifesto may be written the way it is, which is, these are the things we prefer, these things are also valid. So they didn’t disqualify. They just said, we favor these things in this context, but nothing about it is declarative that says If you don’t do it like this, you will fail, it just says these have proven time after time to be valuable patterns by which we’ve all experienced value-based success with our clients.

0:30:38.0 D Lane: And I think to that point, oftentimes, especially large companies that will say, Well, that works again, this idea that works for a startup, that works if there are only 10 people, it doesn’t work when you’ve got hundreds or thousands of people. It does work. I’ve seen it work, I’ve helped companies achieve this, not the majority of companies I’ve worked with because they didn’t want to believe it would work, they were too… They believed any level of change is a risk, and so therefore it was riskier to make that type of change where something is believed to be the level of perfect-ness is related to the lack of risk associated with something, the fact that we’ve done something three times and repeated it.

0:31:23.2 D Lane: Well, it must have very little risk, not necessarily, but again, we tend to view things in these very binary terms, every day we should be learning, we should be innovating, we should invite those things, we’re already saying we’re welcoming changing requirements. But again, we’re in an environment where we’re going to find motivated individuals and we’re going to trust them to get the job done, if these things are true, [chuckle] let’s talk about the measure of progress and how much progress you’re really getting. Are you really improved to delivery of value or you just… Is it all on paper?

0:31:58.8 M Edwards: And so far, we’re still talking about people, we’re still talking about relationships, and we called it out a little earlier, but in my own personal experience, I have found the ability to adapt and add value to a client is absolutely directly proportional to the attitudes and aptitudes of the people on the team. So putting together your team, building your company, it’s people.

0:32:26.8 D Lane: I completely agree. I think another way to characterize that relative to this conversation is, does the team… When the team is discussing something, do they see possibilities or do they see constraints? That’s the thing we talked about, creating an environment and supporting them and then trusting them to get it done. Well, that’s part of the environment. And if your answer is, I don’t know, or no, they see constraints. Well, if you’re responsible for helping to build or support that environment, that’s a chance for you as a leader to say, we have a lot of room where we can improve with agility and I’m going to… This is the biggest way that I can help.

0:33:04.8 M Edwards: So do your people see possibilities or do they see constraints? That is lovely. Wonderful. Well worded. Let me jump us to the next one because this is fun. Simplicity, the art of maximizing the amount of work not done is essential. There are so many places to go, take that conversation. Simplicity, from my perspective, one of its implementations is know when to talk, know when to shut up.

0:33:39.7 D Lane: To me, this is two principles in one, the first one is, simplicity is essential. That’s the key idea. Now, the second part of that, okay, well, simplicity could be in lots of different ways, that’s very vague. What do you possibly mean? The art of maximizing the amount of work not done. I relay a lot of firsthand experience that I’ve had with teams where there was some desire by some leaders somewhere to say We need to do better, and I would end up working with that group as part of that group in some capacity and would… At some point, you see a direct crossroads where you can either continue to always do whatever it is we’ve always done, and we’ll keep getting those results more or less, plus or minus some negligible amount, and oftentimes that… Interestingly enough, that negligible amount, the fact that it moved could be considered a great win if the politics are heavy in an arena, but the reality is, and knowing the distinction from my standpoint, who decides what’s valuable…

0:34:48.8 M Edwards: Left alone, a developer, will struggle with the definition of done. If there is no declarative and there’s no client interaction and there’s no one sitting around, the developer understandably wants to do a good job, they want to deliver value, they want to do the thing that’s necessary in order to provide the wind that the client’s looking for. But absent a definition of done, there could be a whole lot of extra work produced that was never needed, and so one of the ways that I back into this is, if we’re doing these iterations or this frequent delivery and constant communication with a client, and we’re walking together, step by step by step-by-step, many moments a day, many days in the week, many weeks in the month, and so on, we’re going to discover the definition of done together, and that means we won’t have spent time building things that will never get used, or building things that no one asked for, or building things in a way that they were never requested because we were lockstep the entire time. So that’s one way I back into this also is if I have a frequent iterative relationship with you, communicative and then deliverable for re-factor loops and so forth, I deliver the thing that I need to deliver and nothing more and nothing less than we’re done, and that helps manage my cost of acquisition and also impacts my cost of ownership in the long term.

0:36:20.8 D Lane: I think you pointed out some very important things for a lot of the business-minded folks. I’ve used the same approach to help teams and leaders understand that the plan they have most likely includes some things that they don’t need. Well, how do we identify which one they are? Well, first of all, let’s make sure we’re building the right thing, have you talked to your customers? Well, we talked to three, but I’m an expert in this area. I’ve been doing this be 25 years. I’ve been in this role for 15. I know this like the back of my… Have you talked to your customers? And typically, I relay a first-hand experience about dealing with a product owner, even a brand new product owner, never been a product owner before, but someone who knew the domain and was willing to talk to the customers when none of the people above this PO were willing to talk to the customers because they were so convinced that they were blinded by their accepted understanding of what the customers needed, that they had built a backlog that was years out into the future.

0:37:41.3 D Lane: And we were able to talk to customers and identify a single feature set, and in a matter of less than a couple of months, we were able to start from scratch using a technology stack that was foreign to this company, and we were able to work in a very iterative fashion with new skill sets like user experience people, which were believed to be only if you’re doing a brand new product, there was a lot of you’re in a box, and we’ve defined and shaded the box this way, and we were able to very focus on the simplicity, and for the first time ever, in multiple decades at a user conference of this company, which is an international company, we were able to demonstrate working software, ever.

0:38:29.1 D Lane: Typically, it’s all PowerPoint, typically it’s all wave your hands and talk about it, and typically it’s all VPs or whatever doing these types of things. For the first time, our new product owner, he’s only been a product owner now for a few months, was able to get up and say, we talk to this set of customers and their profile is like this, this is a set of features that we heard from the market. Here, let me show you what we’ve built so far, and we’d like to get your feedback, and as I understand it, for the first time only standing ovation because it was the first time that the users felt like that you’re being heard.

0:39:09.3 D Lane: This saved multiple clients who were basically waiting for this particular conference and whatever was going to be shown to make the determination whether they were going to continue with this customer or not, and these are multi-million dollar international. This is the biggest of the big, this is not small fry, this is not a start-up, this is a company that’s gotten decades and they’re number one in multiple markets around the world, and yet they were struggling with putting things in a box and best practices and the way we’ve always done it, we know this our domain and our customers when in reality they didn’t, they somehow…

0:39:45.2 D Lane: And I’m not… This is not a blame, this is not a fault, it’s just a reality of some focusing on simplicity, the amount of work that we did not do that was on the list was worth millions of dollars of development time, not even counting support and maintenance and training and all of that, we did not do that and we delivered simplicity with a different approach to the point that that became now the experience that they were looking for. They were looking for other parts of the system to now begin to behave this way and take the user as a priority, so it demonstrated a way forward where before they could never do it because technologically, the legacy code, the technical debt was just insurmountable. But here we demonstrated a new path forward and again, got first-hand customer approval, we got the delighted customer, they were the standing ovation, they’re like, “Yes, this is what we want. When can we have it?” ‘Cause obviously now they’re seeing working software. Before we go on, I’m wondering if… An example for barbecue, for simplicity, might be useful. One thing that occurs to me is, we’ve talked a lot about brisket, and there’s a lot of different techniques as we mentioned for different folks, and they will swear that this is the way they get their superb repeatable results.

0:41:09.2 D Lane: But in the case of brisket, a common strategy, and what I was taught for pretty much everything I ever saw was that you need to trim off almost all of the fat, most people buy what’s called a packer, brisket. It’s the big one you see in the grocery store when it’s on sale for Memorial Day or whenever you can catch one on sale, and they’re typically in the order from 8 to 12 pounds, sometimes up to 16 pounds, half of that weight is fat. The butcher cuts it in such a way that there’ll be fat on across the back, called the fatback of the flat all the way across the backside of the brisket, and I was taught well, okay… More or less, it seemed that the general prevailing thinking was no more than an inch of that, that you do want fat in general because the fat’s what melts into the meat and moisturizes it, that’s the chemistry that’s going on on the smoker, but low and slow allows the fat to basically moisturize and tenderize the meet over a period of time to the point that it becomes the soft pasty thing that you get out the end, and you’re going, “Yes, this is what I wanted.”

0:42:24.8 D Lane: So no fat, which I’ve actually tried that because I found some people who said, “This is my strategy.” I’ve tried the no fat, for me that was more difficult, it was not as repeatable. The results weren’t what I was looking for, but all the strategies that I heard about cutting the fat, literally pun intended, across the brisket, got me more or less the same results, so when watching one particular guy on TV, he didn’t trim any fat of his. And I thought, okay, insanely enough, I haven’t tried that. It’s simple, you wash it, but don’t cut it, because trimming the fat from a brisket can take a good deal of time, so I don’t trim it, I put it on there and dadgummit if that wasn’t as good as anything else I had done, as far as the level of effort that went into it, so the simplicity of that turned out that it was essential in order for me to get an easier, a less time-consuming effort. And if you’re doing multiple briskets you multiply that times four or five, 10, however many you’re doing, so this becomes… You’re actually simplifying the whole process considerably, it becomes now a much easier process for a much less experienced person to be able to get consistent results. Wash your meat, don’t worry about the fat on the back, place it on the smoker… Use rub or marinade, or if you’re doing anything in particular there, and then put it on the smoker when it’s…

0:44:05.0 D Lane: But there’s a few other things, like I’ve learned, for example, let your meat come up to room temperature. For years and years, I would take it out of the refrigerator and we were concerned about the meat sitting on the counter for more than 10 or 15 minutes, not being in the refrigerator, but in reality, the density of the fat will keep the overall piece of meat at a safe temperature for a significant amount of time, so it’s really not an issue unless you’re going to eat out half the day or something like that. So even an hour, not a problem. So there’s things like that to just make the whole process simpler, managing the fire can be the same way, there’s lots of simplicity things, and they become about maximizing the amount of work not done. I don’t want a 295-step method because it’s complex, and my barbecue is the best, I would like to have a method that’s four steps that I could teach my grandkids.

0:45:08.4 M Edwards: Thank you for joining Derek and I, as we explore the Agile Manifesto. I hope you return for the final episode of this series when we cover the last two principles, I also encourage you to subscribe to the Long Way Around the Barn.

0:45:25.8 Speaker 3: The Long Way Around the Barn is brought to you by Trility consulting, where Matthew serves as the CEO and president. If you need to find a more simple, reliable path to achieve your desired outcomes visit

0:45:42.5 M Edwards: To my listeners, thank you for staying with us. I hope you’re able to take what you heard today and apply it in your context, so that you’re able to realize the predictable repeatable outcomes you desire for you, your teams, company and clients. Thank you.


Approaching Talent Acquisition with Empathy

In working relationships, Scott Albert communicates naturally with transparency and empathy. These personal traits have served him throughout a successful career, enabling rapidly expanding organizations by developing strategic sourcing. He is excited for his fingerprint to be a part of Trility Consulting’s continued growth.

Scott had opportunities to transition into sales over the years but it never felt right to him. The talent acquisition aspect of scaling a business is where he belongs, “I find joy in helping someone improve their situation. Understanding where candidates are at in their careers, where they want to be, and if a move makes sense for them. It isn’t something I take lightly.” By following his passion, Scott has helped hundreds of candidates advance their careers and empowered businesses to grow.

At Trility, and especially in People Operations, we want to care for, enable, and equip all teammates. Delivering what we said, and when we said is the minimum standard when serving others. Scott Albert has seen success in his career because he has a core desire to go above and beyond. He operates with authenticity and true caring.  

Jennifer Davis/ Vice President of People Operations.

Trility is excited to welcome Scott to its team of lifelong learners. The advice he frequently shares with his wife and three kids will be a welcomed reminder to our teams, “It’s okay to fall, as long as you get back up and try again.”

Connect with Scott Albert

Interested in joining the Trility team? Email or connect with Scott Albert on LinkedIn. Check out Scott’s articles for interview advice or career tips.

About Trility

Comprised of technologists and business consultants, Trility helps organizations of all sizes achieve business and technology outcomes. Clients appreciate that our teams solve problems contextually and bring their people along to ensure a reduced cost of ownership long after the engagement is done. Headquartered in Des Moines, Iowa, our people live everywhere, and we serve clients from all corners of the United States and globally.

We’re Growing

Trility Consulting made Inc. 5000 list for fastest growing companies due to achieving 131% financial growth in three years and continues to have career opportunities for people interested in becoming more today than yesterday.


A Passion for Research and Strategy to Drive Content Marketing

A professional journey can take many turns throughout a person’s lifetime. For Claire Damon, hers took a dramatic one before finishing college, “I spent a year in New Zealand during college, and it shifted my perspective. I developed an interest in social justice and the environment that led me to not seek out a ‘true’ marketing job right out of college.”

Instead, Claire spent time as a research analyst in the technology industry where she focused on learning how software is created and, specifically, how algorithms impact results. This eventually piqued her interest in inbound marketing and led her back to marketing by taking a role in the nonprofit sector before joining Trility as a Content Marketer. 

Claire’s drive to bring value and validate results is something Trility seeks out in every candidate. However, her passion to learn and research means she keeps widening her perspective and brings thoughtful, concrete strategies and ideas for our team to leverage.


Proven Success

At her previous position, her fundraising strategy helped the organization address the challenges that COVID brought in 2020. “In lieu of a gala, I pitched a 10-minute documentary to capture Abide’s story of what they were trying to accomplish in North Omaha. The Lights of Hope campaign exceeded the goals we set during a very challenging time.” 

An Iowa native, Damon moved to Des Moines and sought out a full-time role in marketing that would provide flexibility and growth opportunities in a team environment. “I was impressed with Trility’s track record of keeping its commitments to its clients and the transparency throughout the interview process,” shared Claire. “It reinforced that I would have the autonomy to own my work and responsibilities.”

Connect with Claire

Connect with Claire on LinkedIn.

About Trility

Comprised of technologists and business consultants, Trility helps organizations of all sizes achieve business and technology outcomes. Clients appreciate that our teams solve problems contextually and bring their people along to ensure a reduced cost of ownership long after the engagement is done. Headquartered in Des Moines, Iowa, our people live everywhere, and we serve clients from all corners of the United States and globally.

We’re Growing

Trility Consulting made Inc. 5000 list for fastest growing companies due to achieving 131% financial growth in three years and continues to have career opportunities for people interested in becoming more today than yesterday.