Do we still need to talk about Agile methodologies, or is it just the way we work now? Have we just bought into the hype and lost sight of the most important thing: delivering value? In this episode of the Scaling Tech Podcast, we speak with Bob Payne, SVP for Agile Training and Coaching at Lithespeed about his journey to Agile Leadership transformations, his beginnings in Extreme Programming, and if the Agile community has lost the plot. Join us for this discussion with Bob about making sure that we stay focused on delivering real value to our customers.
Bob Payne is an early adopter of Extreme Programming and Scrum. He has worked exclusively as an industry leading Lean+Agile Transformation leader since 1999, helping individuals and organizations achieve results with Agile methods. He has worked in small startups, fortune 100 organizations and government with teams, programs and executives. He is the SVP of Agile Training and Coaching at LitheSpeed. As a thought leader in Agile, Bob is the host of the Agile Toolkit Podcast, founder of Agile Philanthropy, Chair of the Agile DC conference, organizer and speaker at national and international conferences. With nearly 20 years of practical hands-on Agile experience, Bob has served as a trusted advisor to executives, teams and management at leading firms, including United States Citizenship and Immigration Services, The IRS, Nike, Freddie Mac, Fannie Mae, National Geographic, Nationwide Insurance, Royal Bank of Canada, Samsung, and Walmart.
If you have ever been involved with an agile transformation, then you won’t want to miss this episode!
You can learn more about Bob’s work at Lithespeed.com and by subscribing to the Agile Toolkit Podcast
Listen on Spotify
Listen on Apple Podcasts
Watch the video:
Show notes with links to jump ahead are below
Show Notes from Episode 14 – Bob Payne on “Has Agile Lost the Plot?”
Timestamp links will open that part of the show in YouTube in a new window
- 00:00 Opening quote from Bob about how the creators of many agile methods wanted to sell them to make a nice living and to help teams out, they became attached to the processes and forgot about the experimentation part.
- 01:12 Arin and David intro the episode. Arin talks about how he learned many lessons from Bob Payne early in his agile coaching career and that he’s tried to apply those in his work with David in building AgilityFeat. Arin notes that Bob, David and himself have all been involved in agile for over 20 years, and he and David agree that makes it a good time to consider what has happened in the agile industry, but good and bad.
- 04:20 The conversation with Bob starts, and Arin introduces him as an early adopter of Extreme Programming and Scrum. He has worked exclusively as an industry leading Lean+Agile Transformation leader since 1999, helping individuals and organizations achieve results with Agile methods. He has worked in small startups, fortune 100 organizations and government with teams, programs and executives. He is the SVP of Agile Training and Coaching at LitheSpeed. As a thought leader in Agile Bob is the host of the Agile Toolkit Podcast, founder of Agile Philanthropy, Chair of the Agile DC conference, organizer and speaker at national and international conferences. With nearly 20 years of practical hands-on Agile experience, Bob has served as a trusted advisor to executives, teams and management at leading firms, including United States Citizenship and Immigration Services, The IRS, Nike, Freddie Mac, Fannie Mae, National Geographic, Nationwide Insurance, Royal Bank of Canada, Samsung, and Walmart.
- 05:05 Bob notes how he and Arin have known each other for a very long time. Arin asks how Bob got started in transformational leadership and agile coaching. Bob notes he had reached an inflection point in his previous career as a programmer. He moved into project management, but really hated the project management part even though he loved the delivery work. He told his development manager about how projects were always late, requirements change all the time, and yet we demand predictability? It made zero sense to Bob. His development manager suggested a Microsoft Project Manager course as the solution, which was defnitely not the solution! So Bob quit.
- 08:20 Bob wanted to go back to being more technical, and he went to the StarEast conference on testing in DC. While there he ran into a mentor who recommended he check out Ron Jeffries’ work, who was talking about Extreme Programming and the book by Kent Beck. This introduced Bob to iterative ways of development. Bob attended a “birds of a feather” session that evening and was able to meet Ron, who was his first coach and inspired him in the space of technical agility.
- 10:30 Bob decided on the spot that this was what he wanted to do. He became a local expert in the DC region. He learned to focus on what the customer wants first, and what is most risky, and then move on to other things. Later on Bob realized this is exactly how electrical engineering works and so it lined up well with his background. To troubleshoot a circuit, you isolate components and test them in isolation, and then build them from there. That is how extreme programming works too with Test Driven Development.
- 13:00 Bob got a call from his mentor Flavio who wanted to run an XP project with Ron and Bob. Bob started pair programming with others who became part of Lithespeed, such as Raj Indugula and George Lively. Sanjiv Augustine was brought in as the “adult oversight” as a project manager, and that’s how they all met. This was their initial experience doing “agile” before the agile manifesto existed. Sanjiv began to try and build an agile practice in that organization.
- 16:42 Sanjiv and Bob did a large scaled extreme programming project where 8 teams worked across a company, and they implemented a “team of teams” meeting to coordinate across the teams. That looked similar to the LeSS framework and agile scaling frameworks today. By that time, the Scrum Alliance was being started and that certification process became the “secret weapon” of Scrum. That certification process really helped Scrum to become popular, and so he did a lot of work in that area because that’s where the projects where. However, they tried to always stay focused on getting stuff done. By 2005 Bob became a Scrum Trainer and also started podcasting at the same time with his Agile Toolkit Podcast.
- 19:52 Agile is at an interesting inflection point, where we are starting to see organizations say “we are no longer focused on agile.” Capital One said that they expect agile to be the normal way of working now, and so they decided they don’t need a separate agile practices community. Bob feels that agile has lost the plot a bit, that the community (generally speaking) has lost their focus on getting stuff done. Too much of the community has focused on the team building experiences, which are necessary, but not sufficient. A great scrum team that is not delivery the right work is not useful in the system overall. If the team doesn’t know why they are building what they are building, then they cannot be successful.
- 22:30 Teams get too focused on things they can control, like velocity, and start to ignore things that they have less control of because they may be outside of the team. Those bigger questions are things like “who is our customer?” In XP, you worked side by side with the customer in small teams, which eliminated these problems. Agile is necessary, but not sufficient. Technical innovation is now centered in the DevOps community. Bob notes you can’t do Agile without DevOps technical practices.
- 25:40 Arin paraphrases David Hussman by saying that “if you’t know where you’re going … it’s easy to iteratively not get there.” Which is to say that agile is great, but you still need to combine it with strategy, budgeting, executive support, and technical practices in order to hit optimal efficiency.
- 26:45 David asks what struck a chord with Bob about agile early on? Bob says he wishes he had a good answer for that! It’s hard to attribute because he feels he was just kind of at the right place at the right time, without much to lose. And so kind of like in Malcolm Gladwell’s book “Outliers”, agile became as good a thread to pull as any other for Bob. But the concentraction on engineering practices drew him in, and he rapidly understood the power of iterations. For David, the humane and safe approach for the developer really resonated early on, and then he next discovered how agile handles risk management and that really appealed to him. David liked how agile puts the merit of the software engineer in the right place, and not a factory approach.
- 30:55 Arin asks how did we go from our idealistic views of getting more meaningful work done, to now, where companies like Capital One are getting rid of scrummasters. Is that a sign of failure or maturity, that the role is not needed? Is Agile failing? If so, where and how?
- 32:00 Bob notes that DevOps may be the future of agile, but “it’s the people stupid” is still very important. We have to remember “individuals and interactions over tools and interactions”, and DevOps can get too focused on tools. But in many agile methods, we have also become too focused on tooling, and this contributes to failures in agile.
- 34:00 Build into the manifesto, is the idea that any process we’re using, it must be situationallly appropriate to the people and projects involved. We have to be able to try experiments, and we learned that lesson in the past with experiements in Lean manufacturing. Even the Toyota manufacturing process is very different – there are some consistent ideas and principles, but the rest is very different. The creators of agile methods though became too attached to individual processes and forgot the experimentation part. Empirical process control is built into Scrum, but very few Scrum teams tweak their processes. That was the moment that Agility stopped being Agile. The reason the manifesto came to be is that all these people were trying to solve similar challenges. They were all just making stuff up! But once people started investing energy into dogmatic ways of doing things, we lost the ability to innovate. There are exceptions to that rule of course.
- 37:43 David remembers the moment he decided to focus his life more towards building products for the sake of the customer value, in contrast to trying to spend more time in the agile community as he had been previously. He decided not to try and get too involved in the agile community because it was clear to him that there was a spirit of elitism. He felt he loved Scrum, but didn’t need the club that came with it. He preferred to do things for the value of it instead of the value of the club.
- 39:45 Bob thinks that he and others didn’t caveat Scrum enough in the past. He should have said “do this for a while, and then add in other stuff.” He goes back to his work at Nationwide where Arin also was an agile coach. At that client, they were able to experiment a lot, but in many others, Scrum has just become the new bureaucracy. “You’re not doing user stories right!” Arin asks how do you encourage the right kind of innovation, and not become dogmatic?
- 41:58 Bob says there’s not a right answer to that, but there are a lot of wrong answers. A focus on product and value delivery is excellent, but it’s not always clear in every organization (think of a fire department or government organization). Teams are expensive endeavours, and so we have to keep a connection to the value they deliver, instead of just focusing on keeping a team busy (but who is not delivering value).
- 44:26 Bob says team should be able to answer these questions: “Are we getting better at producing value and delivering it through the organization?” “Do we have appropriate quality in place?” (this vary with type of projects) “Is Team Sustainability remaining the same or increasing?” (this is where team health comes in) Teams that are improving in these areas and delivering value are the teams we should value the most in a lean organization.
- 47:44 David adds in that he came to a realization some years ago that developers who care about value and who wants to be connected to the customer is rare. Bob says that’s ok that not all developers are interested in that. They need to understand though that the reason they have a job is creating value, and so a system that promotes understanding why will allow engineers who want to contribute their best work and innovate the most will thrive. We need to connect our work with the value that is created.
- 51:00 Knowledge workers (including developers) are more highly engaged by the value that they create, by understanding why they are doing what they are doing. It’s not just about theory – let’s solve this puzzle as a means to get something real done in the world. So while we need people who are passionated about specific pieces of technology, but we also need people who are focused on why we are doing this work to begin with, and who get excited about delivering value to customers.
- 53:30 Arin asks if we agree that Agile has lost the plot? Bob says maybe it has, some parts have lost the plot. Arin asks what gives Bob hope in the future of the agile movement and the next set of software developers? Bob responds that it is the product mindset, and the movement in organizations to focus on the marketplace and the product they deliver. It is about a hyper focus on the customer and moving backwards from that value stream to see who needs. He mentioned the books Project to Product by Mik Kersten, Team Topologies by Matthew Skelton and Manuel Pais, and unFIX Model by Jurgen Appelo. All of those are extensions of agile, since they require the rapid development of a product that the marketplace puts value on. These newer movements encompass the entire organization, including business organizations and the users of the solution being produced. Bob describes it as a “Back to the Future” moment that is a throwback to Lean. “Value is produced in the hands of the customer, and everything upstream is subordinated to that.”
- 57:45 Agile is not dead, it’s just being repackaged as Value Flow. The purpose is to flow value and measure that value in the marketplace, and to use adaptive governance to control the system. It’s still all based on the 80 year old technology of Lean thinking, applied to knowledge work.
- 1:00:00 Arin summarizes what teams need to do based on this conversation with Bob: 1) Focus on increasing the value flow through the organization, 2) Using an appropriate level of quality, 3) Improving team sustainability. Focus on that, ignore the hype, and you’re doing well. Bob closes us out with a quote from Chuck D and Flavor Flav … “Don’t believe the hype!”
Links from Episode 14 – Bob Payne on “Has Agile Lost the Plot?”
- Lithespeed.com – Information on Bob and the team of lean/agile experts at Lithespeed
- Agile Toolkit Podcast – Bob’s long running podcast with interviews with many agile experts and founders of agile methodologies
- AgileDC.org – Annual conference in Washington DC, which is organized by Bob and focuses on goverment and large enterprise use of Agile and Lean methodologies.
- About Bob Payne – Bob’s bio on the Lithespeed page includes links to some of his presentations
- Bob Payne on LinkedIn
- Other Books mentioned by Bob:
- Extreme Programming Explained by Kent Beck, the “white book” that Bob referred to as a foundational early piece on extreme programming and what were later called agile methods.
- Project to Product by Mik Kersten
- Team Topologies by Matthew Skelton and Manuel Pais
- Jurgen Appelo – Bob mentioned Jurgen Appelo’s “unFIX model” which you can learn more about in this presentation to Agile Austria, and Jurgen’s website includes links to his other writings.