Podcasts about extreme programming explained

 Andy discusses the importance of iteration and feedback in the development process. He emphasizes the difference between iteration and incremental progress, sharing a story from Kent Beck's 'Extreme Programming Explained' to illustrate the concept. Mon-Chaio returns next week when they will discuss the Peter Principle. Stay tuned! References Extreme Programming Explained - https://archive.org/details/extremeprogrammi00beck

Bio Luke Hohmann is Chief Innovation Officer of Applied Frameworks. Applied Frameworks helps companies create more profitable software-enabled solutions. A serial entrepreneur, Luke founded, bootstrapped, and sold the SaaS B2B collaboration software company Conteneo to Scaled Agile, Inc. Conteneo's Weave platform is now part of SAFe Studio. A SAFe® Fellow, prolific author, and trailblazing innovator, Luke's contributions to the global agile community include contributing to SAFe, five books, Profit Streams™, Innovation Games®, Participatory Budgeting at enterprise scale, and a pattern language for market-driven roadmapping. Luke is also co-founder of Every Voice Engaged Foundation, where he partnered with The Kettering Foundation to create Common Ground for Action, the world's first scalable platform for deliberative decision-making. Luke is a former National Junior Pairs Figure Skating Champion and has an M.S.E. in Computer Science and Engineering from the University of Michigan. Luke loves his wife and four kids, his wife's cooking, and long runs in the California sunshine and Santa Cruz mountains.    Interview Highlights 01:30 Organisational Behaviour & Cognitive Psychology 06:10 Serendipity 09:30 Entrepreneurship 16:15 Applied Frameworks 20:00 Sustainability 20:45 Software Profit Streams 23:00 Business Model Canvas 24:00 Value Proposition Canvas 24:45 Setting the Price 28:45 Customer Benefit Analysis 34:00 Participatory Budgeting 36:00 Value Stream Funding 37:30 The Color of Money 42:00 Private v Public Sector 49:00 ROI Analysis 51:00 Innovation Accounting    Connecting   LinkedIn: Luke Hohmann on LinkedIn Company Website: Applied Frameworks    Books & Resources   ·         Software Profit Streams(TM): A Guide to Designing a Sustainably Profitable Business: Jason Tanner, Luke Hohmann, Federico González ·         Business Model Generation: A Handbook for Visionaries, Game Changers, and Challengers (The Strategyzer series): Alexander Osterwalder, Yves Pigneur ·         Value Proposition Design: How to Create Products and Services Customers Want (The Strategyzer Series): Alexander Osterwalder, Yves Pigneur, Gregory Bernarda, Alan Smith, Trish Papadakos ·         Innovation Games: Creating Breakthrough Products Through Collaborative Play: Luke Hohmann ·         The ‘Color of Money' Problem: Additional Guidance on Participatory Budgeting - Scaled Agile Framework ·         The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries ·         Extreme Programming Explained: Embrace Change 2, Kent Beck, Cynthia Andres ·         The Mythical Man-Month: Essays on Software Engineering: Brooks, Frederick Phillips ·         Understanding Comics: The Invisible Art, Scott McCloud ·         Ponyboy: A Novel, Eliot Duncan ·         Lessons in Chemistry: A Novel, Bonnie Garmus, Miranda Raison, Bonnie Garmus, Pandora Sykes ·         What Happened to You?: Conversations on Trauma, Resilience, and Healing, Oprah Winfrey, Bruce D. Perry ·         Training | Applied Frameworks   Episode Transcript Intro: Hello and welcome to the Agile Innovation Leaders podcast. I'm Ula Ojiaku. On this podcast I speak with world-class leaders and doers about themselves and a variety of topics spanning Agile, Lean Innovation, Business, Leadership and much more – with actionable takeaways for you the listener.  Ula Ojiaku   So I have with me Luke Hohmann, who is a four time author, three time founder, serial entrepreneur if I say, a SAFe fellow, so that's a Skilled Agile Framework fellow, keynote speaker and an internationally recognised expert in Agile software development. He is also a proud husband and a father of four. So, Luke, I am very honoured to have you on the Agile Innovation Leaders podcast. Thank you for making the time. Luke Hohmann Thank you so much for having me, I'm very happy to be here, and hi everyone who's listening. Ula Ojiaku Yes, I'm sure they're waving back at you as well. I always start my conversations with my guests to find out about them as individuals, you know, so who is Luke? You have a BSc in Computer Science and an MSc in Computer Science and Engineering, but you also studied Cognitive Psychology and Organisational Behaviour in addition to Data Structures and Artificial Intelligence. AI is now making waves and is kind of at the forefront, which is interesting, you had the foresight to also look into these. So my question is, what took you down this path? Luke Hohmann Sure. I had a humble beginning in the world of technology. I worked for a large company, Electronic Data Systems, and it was founded in the mid 60s by a gentleman named Ross Perot, and it became a very, very large company. So my first job at Electronic Data Systems was working in a data centre, and we know what data centres are, but back then, data centres were different because they were predominantly mainframe-based data centres, and I would crawl underneath the floor, cabling the computers and cabling networking equipment. Now, when we think networking, we're really thinking one of two kinds of networking. We think of wireless networking or we think of some form of internet networking, but back in those days, there were varieties of network protocols, literally the standards that we use now weren't invented yet. So it was mainframe networking protocols and dial ups and other forms of networking protocols. From there, I worked my way from beneath the ground up. I had some great managers who saw someone who was worthy of opportunity and they gave me opportunity and it was great. And then eventually I started working in electronic data systems and there was, the first wave of AI came in the mid 80s and that's when we were doing things like building expert systems, and I managed to create with a colleague of mine, who's emerged as my best friend, a very successful implementation of an expert system, an AI-based expert system at EDS, and that motivated me to finish off my college degree, I didn't have my college degree at the time. So EDS supported me in going to the University of Michigan, where as you said, I picked up my Bachelor's and Master's degree, and my advisor at the time was Elliot Soloway, and he was doing research in how programmers program, what are the knowledge structures, what are the ways in which we think when we're programming, and I picked up that research and built programming environments, along with educational material, trying to understand how programmers program and trying to build educational material to teach programming more effectively. That's important because it ignited a lifelong passion for developing education materials, etc. Now the cognitive psychology part was handled through that vein of work, the organisational behaviour work came as I was a student at Michigan. As many of us are when we're in college, we don't make a lot of money, or at university we're not wealthy and I needed a job and so the School of Organisational Behaviour had published some job postings and they needed programmers to program software for their organisational behaviour research, and I answered those ads and I became friends and did the research for many ground-breaking aspects of organisational behaviour and I programmed, and in the process of programming for the professors who were in the School of Organisational Behaviour they would teach me about organisational behaviour and I learned many things that at the time were not entirely clear to me, but then when I graduated from university and I became a manager and I also became more involved in the Agile movement, I had a very deep foundation that has served me very well in terms of what do we mean when we say culture, or what do we mean when we talk about organisational structures, both in the small and in the large, how do we organise effectively, when should we scale, when should we not scale, etc. So that's a bit about my history that I think in terms of the early days helped inform who I am today. Ula Ojiaku Wow, who would have thought, it just reminds me of the word serendipity, you know, I guess a happy coincidence, quote unquote, and would there be examples of where the cognitive psychology part of it also helped you work-wise? Luke Hohmann Yeah, a way to think about cognitive psychology and the branch that, I mean there's, psychology is a huge branch of study, right? So cognitive psychology tends to relate to how do we solve problems, and it tends to focus on problem solving where n = 1 and what I mean by n is the number of participants, and where n is just me as an individual, how do I solve the problems that I'm facing? How do I engage in de-compositional activities or refinement or sense making? Organisational behaviour deals with n > 1. So it can deal with a team of, a para-bond, two people solving problems. It can deal with a small team, and we know through many, many, many decades of research that optimal team structures are eight people or less. I mean, we've known this for, when I say decades I mean millennia. When you look at military structure and military strategy, we know that people need to be organised into much smaller groups to be effective in problem solving and to move quickly. And then in any organisational structure, there's some notion of a team of teams or team engagement. So cognitive psychology, I think, helps leaders understand individuals and their place within the team. And now we talk about, you know, in the Agile community, we talk about things like, I want T-shaped people, I want people with common skills and their area of expertise and by organising enough of the T's, I can create a whole and complete team. I often say I don't want my database designer designing my user interface and I don't want my user interface designer optimising my back end database queries, they're different skills. They're very educated people, they're very sophisticated, but there's also the natural feeling that you and I have about how do I gain a sense of self, how do I gain a sense of accomplishment, a sense of mastery? Part of gaining a sense of mastery is understanding who you are as a person, what you're good at. In Japanese, they would call that Ikigai, right, what are the intersections of, you know, what do I love, what am I good at, what can I make a living at and what do people need, right? All of these intersections occur on an individual level, and then by understanding that we can create more effective teams. Ula Ojiaku Thank you. I've really learned something key here, the relationship between cognitive psychology and organisational behaviour, so thanks for breaking it down. Now, can we go quickly to your entrepreneurship? So there must be three times you started three times a company and you've been successful in that area. What exactly drives you when it comes to establishing businesses and then knowing when to move on? Luke Hohmann Sure. I think it's a combination of reflecting on my childhood and then looking at how that informs someone when they're older, and then opportunities, like you said, serendipity, I think that's a really powerful word that you introduced and it's a really powerful concept because sometimes the serendipity is associated with just allowing yourself to pursue something that presents itself. But when I was young, my father died and my mum had to raise six kids on her own, so my dad died when I was four, my mum raised six kids on her own. We were not a wealthy family, and she was a school teacher and one of the things that happened was, even though she was a very skilled school teacher, there were budget cuts and it was a unionised structure, and even though she was ranked very highly, she lost her job because she was low on the hiring totem pole in terms of how the union worked. It was very hard and of course, it's always hard to make budget cuts and firing but I remember when I was very young making one of those choices saying, I want to work in a field where we are more oriented towards someone's performance and not oriented on when they were hired, or the colour of their skin, or their gender or other things that to me didn't make sense that people were making decisions against. And while it's not a perfect field for sure, and we've got lots of improvement, engineering in general, and of course software engineering and software development spoke to me because I could meet people who were diverse or more diverse than in other fields and I thought that was really good. In terms of being an entrepreneur, that happened serendipitously. I was at the time, before I became an entrepreneur in my last job, was working for an Israeli security firm, and years and years ago, I used to do software anti-piracy and software security through physical dongles. This was made by a company called Aladdin Knowledge Systems in Israel, and I was the head of Engineering and Product Management for the dongle group and then I moved into a role of Business Development for the company. I had a couple of great bosses, but I also learned how to do international management because I had development teams in Israel, I had development teams in Munich, I had development teams in Portland, Oregon, and in the Bay Area, and this was in the 2000s. This is kind of pre-Agile, pre-Salt Lake City, pre-Agile Manifesto, but we were figuring things out and blending and working together. I thought things were going pretty well and I enjoyed working for the Israelis and what we were doing, but then we had the first Gulf War and my wife and I felt that maybe traveling as I was, we weren't sure what was going to happen in the war, I should choose something different. Unfortunately, by that time, we had been through the dot-bomb crisis in Silicon Valley. So it's about 2002 at the time that this was going on, and there really weren't jobs, it was a very weird time in Silicon Valley. So in late 2002, I sent an email to a bunch of friends and I said, hey, I'm going to be a consultant, who wants to hire me, that was my marketing plan, not very clever, and someone called me and said, hey, I've got a problem and this is the kind of thing that you can fix, come consult with us. And I said, great. So I did that, and that started the cleverly named Luke Hohmann Consulting, but then one thing led to another and consulting led to opportunities and growth and I've never looked back. So I think that there is a myth about people who start companies where sometimes you have a plan and you go execute your plan. Sometimes you find the problem and you're solving a problem. Sometimes the problem is your own problem, as in my case I had two small kids and a mortgage and I needed to provide for my family, and so the best way to do that at the time was to become a consultant. Since then I have engaged in building companies, sometimes some with more planning, some with more business tools and of course as you grow as an entrepreneur you learn skills that they didn't teach you in school, like marketing and pricing and business planning etc. And so that's kind of how I got started, and now I have kind of come full circle. The last company, the second last company I started was Conteneo and we ended up selling that to Scaled Agile, and that's how I joined the Scaled Agile team and that was lovely, moving from a position of being a CEO and being responsible for certain things, to being able to be part of a team again, joining the framework team, working with Dean Leffingwell and other members of the framework team to evolve the SAFe framework, that was really lovely. And then of course you get this entrepreneurial itch and you want to do something else, and so I think it comes and goes and you kind of allow yourself those opportunities. Ula Ojiaku Wow, yours is an inspiring story. And so what are you now, so you've talked about your first two Startups which you sold, what are you doing now? Luke Hohmann Yeah, so where I'm at right now is I am the Chief Innovation Officer for a company, Applied Frameworks. Applied Frameworks is a boutique consulting firm that's in a transition to a product company. So if this arm represents our product revenue and this arm represents our services revenue, we're expanding our product and eventually we'll become a product company. And so then the question is, well, what is the product that we're working on? Well, if you look at the Agile community, we've spent a lot of time creating and delivering value, and that's really great. We have had, if you look at the Agile community, we've had amazing support from our business counterparts. They've shovelled literally millions and millions of dollars into Agile training and Agile tooling and Agile transformations, and we've seen a lot of benefit from the Agile community. And when I say Agile, I don't mean SAFe or Scrum or some particular flavour of Agile, I just mean Agile in general. There's been hundreds of millions of dollars to billions of dollars shoved into Agile and we've created a lot of value for that investment. We've got fewer bugs in our software because we've got so many teams doing XP driven practices like Test Driven Development, we've got faster response times because we've learned that we can create smaller releases and we've created infrastructure that lets us do deployments automatically, even if you're doing embedded systems, we figured out how to do over the air updates, we've figured out how to create infrastructure where the cars we're driving are now getting software updates. So we've created for our business leaders lots of value, but there's a problem in that value. Our business leaders now need us to create a profit, and creating value and creating a profit are two different things. And so in the pursuit of value, we have allowed our Agile community to avoid and or atrophy on skills that are vital to product management, and I'm a classically trained Product Manager, so I've done market segmentation and market valuation and market sizing, I've done pricing, I've done licensing, I've done acquisitions, I've done compliance. But when you look at the traditional definition of a Product Owner, it's a very small subset of that, especially in certain Agile methods where Product Owners are team centric, they're internal centric. That's okay, I'm not criticising that structure, but what's happened is we've got people who no longer know how to price, how to package, how to license products, and we're seeing companies fail, investor money wasted, too much time trying to figure things out when if we had simply approached the problem with an analysis of not just what am I providing to you in terms of value, but what is that value worth, and how do I structure an exchange where I give you value and you give me money? And that's how businesses survive, and I think what's really interesting about this in terms of Agile is Agile is very intimately tied to sustainability. One of the drivers of the Agile Movement was way back in the 2000s, we were having very unsustainable practices. People would be working 60, 80, death march weeks of grinding out programmers and grinding out people, and part of the Agile Movement was saying, wait a minute, this isn't sustainable, and even the notion of what is a sustainable pace is really vital, but a company cannot sustain itself without a profit, and if we don't actually evolve the Agile community from value streams into profit streams, we can't help our businesses survive. I sometimes ask developers, I say, raise your hand if you're really embracing the idea that your job is to make more money for your company than they pay you, that's called a profit, and if that's not happening, your company's going to fail. Ula Ojiaku They'll be out of a job. Luke Hohmann You'll be out of a job. So if you want to be self-interested about your future, help your company be successful, help them make a profit, and so where I'm at right now is Applied Frameworks has, with my co-author, Jason Tanner, we have published a bold and breakthrough new book called Software Profit Streams, and it's a book that describes how to do pricing and packaging for software enabled solutions. When we say software enabled solution, we mean a solution that has software in it somehow, could be embedded software in your microwave oven, it could be a hosted solution, it could be an API for a payment processor, it could be the software in your car that I talked about earlier. So software enabled solutions are the foundation, the fabric of our modern lives. As Mark Andreessen says software is eating the world, software is going to be in everything, and we need to know how to take the value that we are creating as engineers, as developers, and convert that into pricing and licensing choices that create sustainable profits. Ula Ojiaku Wow. It's as if you read my mind because I was going to ask you about your book, Software Profit Streams, A Guide to Designing a Sustainably Profitable Business. I also noticed that, you know, there is the Profit Stream Canvas that you and your co-author created. So let's assume I am a Product Manager and I've used this, let's assume I went down the path of using the Business Model Canvas and there is the Customer Value Proposition. So how do they complement? Luke Hohmann How do they all work together? I'm glad you asked that, I think that's a very insightful question and the reason it's so helpful is because, well partly because I'm also friends with Alex Osterwalder, I think he's a dear, he's a wonderful human, he's a dear friend. So let's look at the different elements of the different canvases, if you will, and why we think that this is needed. The Business Model Canvas is kind of how am I structuring my business itself, like what are my partners, my suppliers, my relationships, my channel strategy, my brand strategy with respect to my customer segments, and it includes elements of cost, which we're pretty good at. We're pretty good at knowing our costs and elements of revenue, but the key assumption of revenue, of course, is the selling price and the number of units sold. So, but if you look at the book, Business Model Generation, where the Business Model Canvas comes from, it doesn't actually talk about how to set the price. Is the video game going to be $49? Is it going to be $59, or £49 or £59? Well, there's a lot of thought that goes into that. Then we have the Value Proposition Canvas, which highlights what are the pains the customer is facing? What are the gains that the customer is facing? What are the jobs to be done of the customer? How does my solution relate to the jobs? How does it help solve the pain the customer is feeling? How does it create gain for the customer? But if you read those books, and both of those books are on my shelf because they're fantastic books, it doesn't talk about pricing. So let's say I create a gain for you. Well, how much can I charge you for the gain that I've created? How do I structure that relationship? And how do I know, going back to my Business Model Canvas, that I've got the right market segment, I've got the right investment strategy, I might need to make an investment in the first one or two releases of my software or my product before I start to make a per unit profit because I'm evolving, it's called the J curve and the J curve is how much money am I investing before I well, I have to be able to forecast that, I have to be able to model that, but the key input to that is what is the price, what is the mechanism of packaging that you're using, is it, for example, is it per user in a SAS environment or is it per company in a SAS environment? Is it a meter? Is it like an API transaction using Stripe or a payment processor, Adyen or Stripe or Paypal or any of the others that are out there? Or is it an API call where I'm charging a fraction of a penny for any API call? All of those elements have to be put into an economic model and a forecast has to be created. Now, what's missing about this is that the Business Model Canvas and the Value Proposition Canvas don't give you the insight on how to set the price, they just say there is a price and we're going to use it in our equations. So what we've done is we've said, look, setting the price is itself a complex system, and what I mean by a complex system is that, let's say that I wanted to do an annual license for a new SAS offering, but I offer that in Europe and now my solution is influenced or governed by GDPR compliance, where I have data retention and data privacy laws. So my technical architecture that has to enforce the license, also has to comply with something in terms of the market in which I'm selling. This complex system needs to be organised, and so what canvases do is in all of these cases, they let us take a complex system and put some structure behind the choices that we're making in that complex system so that we can make better choices in terms of system design. I know how I want this to work, I know how I want this to be structured, and therefore I can make system choices so the system is working in a way that benefits the stakeholders. Not just me, right, I'm not the only stakeholder, my customers are in this system, my suppliers are in this system, society itself might be in the system, depending on the system I'm building or the solution I'm building. So the canvases enable us to make system level choices that are hopefully more effective in achieving our goals. And like I said, the Business Model Canvas, the Value Proposition Canvas are fantastic, highly recommended, but they don't cover pricing. So we needed something to cover the actual pricing and packaging and licensing. Ula Ojiaku Well, that's awesome. So it's really more about going, taking a deeper dive into thoughtfully and structurally, if I may use that word, assessing the pricing. Luke Hohmann Yeah, absolutely. Ula Ojiaku Would you say that in doing this there would be some elements of, you know, testing and getting feedback from actual customers to know what price point makes sense? Luke Hohmann Absolutely. There's a number of ways in which customer engagement or customer testing is involved. The very first step that we advocate is a Customer Benefit Analysis, which is what are the actual benefits you're creating and how are your customers experiencing those benefits. Those experiences are both tangible and intangible and that's another one of the challenges that we face in the Agile community. In general, the Agile community spends a little bit more time on tangible or functional value than intangible value. So we, in terms of if I were to look at it in terms of a computer, we used to say speeds and feeds. How fast is the processor? How fast is the network? How much storage is on my disk space? Those are all functional elements. Over time as our computers have become plenty fast or plenty storage wise for most of our personal computing needs, we see elements of design come into play, elements of usability, elements of brand, and we see this in other areas. Cars have improved in quality so much that many of us, the durability of the car is no longer a significant attribute because all cars are pretty durable, they're pretty good, they're pretty well made. So now we look at brand, we look at style, we look at aesthetics, we look at even paying more for a car that aligns with our values in terms of the environment. I want to get an EV, why, because I want to be more environmentally conscious. That's a value driven, that's an intangible factor. And so our first step starts with Customer Benefit Analysis looking at both functional or tangible value and intangible value, and you can't do that, as you can imagine, you can't do that without having customer interaction and awareness with your stakeholders and your customers, and that also feeds throughout the whole pricing process. Eventually, you're going to put your product in a market, and that's a form itself of market research. Did customers buy, and if they didn't buy, why did they not buy? Is it poorly packaged or is it poorly priced? These are all elements that involve customers throughout the process. Ula Ojiaku If I may, I know we've been on the topic of your latest book Software Profit Streams. I'm just wondering, because I can't help but try to connect the dots and I'm wondering if there might be a connection to one of your books, Innovation Games: Creating Breakthrough Products Through Collaborative Play, something like buy a feature in your book, that kind of came to mind, could there be a way of using that as part of the engagement with customers in setting a pricing strategy? I may be wrong, I'm just asking a question. Luke Hohmann I think you're making a great connection. There's two forms of relationship that Innovation Games and the Innovation Games book have with Software Profit Streams. One is, as you correctly noted, just the basics of market research, where do key people have pains or gains and what it might be worth. That work is also included in Alex Osterwalder's books, Value Proposition Design for example, when I've been doing Value Proposition Design and I'm trying to figure out the customer pains, you can use the Innovation Games Speed Boat. And when I want to figure out the gains, I can use the Innovation Game Product Box. Similarly, when I'm figuring out pricing and licensing, a way, and it's a very astute idea, a way to understand price points of individual features is to do certain kinds of market research. One form of market research you can do is Buy-a-Feature, which gives a gauge of what people are willing or might be willing to pay for a feature. It can be a little tricky because the normal construction of Buy-a-Feature is based on cost. However, your insight is correct, you can extend Buy-a-Feature such that you're testing value as opposed to cost, and seeing what, if you take a feature that costs X, but inflate that cost by Y and a Buy-a-Feature game, if people still buy it, it's a strong signal strength that first they want it, and second it may be a feature that you can, when delivered, would motivate you to raise the price of your offering and create a better profit for your company. Ula Ojiaku Okay, well, thank you. I wasn't sure if I was on the right lines. Luke Hohmann It's a great connection. Ula Ojiaku Thanks again. I mean, it's not original. I'm just piggybacking on your ideas. So with respect to, if we, if you don't mind, let's shift gears a bit because I know that, or I'm aware that whilst you were with Scaled Agile Incorporated, you know, you played a key part in developing some of their courses, like the Product POPM, and I think the Portfolio Management, and there was the concept about Participatory Budgeting. Can we talk about that, please? Luke Hohmann I'd love to talk about that, I mean it's a huge passion of mine, absolutely. So in February of 2018, I started working with the framework team and in December of 2018, we talked about the possibility of what an acquisition might look like and the benefits it would create, which would be many. That closed in May of 2019, and in that timeframe, we were working on SAFe 5.0 and so there were a couple of areas in which I was able to make some contributions. One was in Agile product delivery competency, the other was in lean portfolio management. I had a significant hand in restructuring or adding the POPM, APM, and LPM courses, adding things like solutions by horizons to SAFe, taking the existing content on guardrails, expanding it a little bit, and of course, adding Participatory Budgeting, which is just a huge passion of mine. I've done Participatory Budgeting now for 20 years, I've helped organisations make more than five billions of dollars of investment spending choices at all levels of companies, myself and my colleagues at Applied Frameworks, and it just is a better way to make a shared decision. If you think about one of the examples they use about Participatory Budgeting, is my preferred form of fitness is I'm a runner and so, and my wife is also a fit person. So if she goes and buys a new pair of shoes or trainers and I go and buy a new pair of trainers, we don't care, because it's a small purchase. It's frequently made and it's within the pattern of our normal behaviour. However, if I were to go out and buy a new car without involving her, that feels different, right, it's a significant purchase, it requires budgeting and care, and is this car going to meet our needs? Our kids are older than your kids, so we have different needs and different requirements, and so I would be losing trust in my pair bond with my wife if I made a substantial purchase without her involvement. Well, corporations work the same way, because we're still people. So if I'm funding a value stream, I'm funding the consistent and reliable flow of valuable items, that's what value stream funding is supposed to do. However, if there is a significant investment to be made, even if the value stream can afford it, it should be introduced to the portfolio for no other reason than the social structure of healthy organisations says that we do better when we're talking about these things, that we don't go off on our own and make significant decisions without the input of others. That lowers transparency, that lowers trust. So I am a huge advocate of Participatory Budgeting, I'm very happy that it's included in SAFe as a recommended practice, both for market research and Buy-a-Feature in APM, but also more significantly, if you will, at the portfolio level for making investment decisions. And I'm really excited to share that we've just published an article a few weeks ago about Participatory Budgeting and what's called The Color of Money, and The Color of Money is sometimes when you have constraints on how you can spend money, and an example of a constraint is let's say that a government raised taxes to improve transportation infrastructure. Well, the money that they took in is constrained in a certain way. You can't spend it, for example, on education, and so we have to show how Participatory Budgeting can be adapted to have relationships between items like this item requires this item as a precedent or The Color of Money, constraints of funding items, but I'm a big believer, we just published that article and you can get that at the Scaled Agile website, I'm a big believer in the social power of making these financial decisions and the benefits that accrue to people and organisations when they collaborate in this manner. Ula Ojiaku Thanks for going into that, Luke. So, would there be, in your experience, any type of organisation that's participatory? It's not a leading question, it's just genuine, there are typically outliers and I'm wondering in your experience, and in your opinion, if there would be organisations that it might not work for? Luke Hohmann Surprisingly, no, but I want to add a few qualifications to the effective design of a Participatory Budgeting session. When people hear Participatory Budgeting, there's different ways that you would apply Participatory Budgeting in the public and private sector. So I've done citywide Participatory Budgeting in cities and if you're a citizen of a city and you meet the qualifications for voting within that jurisdiction, in the United States, it's typically that you're 18 years old, in some places you have to be a little older, in some places you might have other qualifications, but if you're qualified to participate as a citizen in democratic processes, then you should be able to participate in Participatory Budgeting sessions that are associated with things like how do we spend taxes or how do we make certain investments. In corporations it's not quite the same way. Just because you work at a company doesn't mean you should be included in portfolio management decisions that affect the entire company. You may not have the background, you may not have the training, you may be what my friends sometimes call a fresher. So I do a lot of work overseas, so freshers, they just may not have the experience to participate. So one thing that we look at in Participatory Budgeting and SAFe is who should be involved in the sessions, and that doesn't mean that every single employee should always be included, because their background, I mean, they may be a technical topic and maybe they don't have the right technical background. So we work a little bit harder in corporations to make sure the right people are there. Now, of course, if we're going to make a mistake, we tend to make the mistake of including more people than excluding, partly because in SAFe Participatory Budgeting, it's a group of people who are making a decision, not a one person, one vote, and that's really profoundly important because in a corporation, just like in a para-bond, your opinion matters to me, I want to know what you're thinking. If I'm looking in, I'll use SAFe terminology, if I'm looking at three epics that could advance our portfolio, and I'm a little unsure about two of those epics, like one of those epics, I'm like, yeah, this is a really good thing, I know a little bit about it, this matters, I'm going to fund this, but the other two I'm not so sure about, well, there's no way I can learn through reading alone what the opinions of other people are, because, again, there's these intangible factors. There's these elements that may not be included in an ROI analysis, it's kind of hard to talk about brand and an ROI analysis - we can, but it's hard, so I want to listen to how other people are talking about things, and through that, I can go, yeah, I can see the value, I didn't see it before, I'm going to join you in funding this. So that's among the ways in which Participatory Budgeting is a little different within the private sector and the public sector and within a company. The only other element that I would add is that Participatory Budgeting gives people the permission to stop funding items that are no longer likely to meet the investment or objectives of the company, or to change minds, and so one of the, again, this is a bit of an overhang in the Agile community, Agile teams are optimised for doing things that are small, things that can fit within a two or three week Sprint. That's great, no criticism there, but our customers and our stakeholders want big things that move the market needle, and the big things that move the market needle don't get done in two or three weeks, in general, and they rarely, like they require multiple teams working multiple weeks to create a really profoundly new important thing. And so what happens though, is that we need to make in a sense funding commitments for these big things, but we also have to have a way to change our mind, and so traditional funding processes, they let us make this big commitment, but they're not good at letting us change our mind, meaning they're not Agile. Participatory Budgeting gives us the best of both worlds. I can sit at the table with you and with our colleagues, we can commit to funding something that's big, but six months later, which is the recommended cadence from SAFe, I can come back to that table and reassess and we can all look at each other, because you know those moments, right, you've had that experience in visiting, because you're like looking around the table and you're like, yeah, this isn't working. And then in traditional funding, we keep funding what's not working because there's no built-in mechanism to easily change it, but in SAFe Participatory Budgeting, you and I can sit at the table and we can look at each other with our colleagues and say, yeah, you know, that initiative just, it's not working, well, let's change our mind, okay, what is the new thing that we can fund? What is the new epic? And that permission is so powerful within a corporation. Ula Ojiaku Thanks for sharing that, and whilst you were speaking, because again, me trying to connect the dots and thinking, for an organisation that has adopted SAFe or it's trying to scale Agility, because like you mentioned, Agile teams are optimised to iteratively develop or deliver, you know, small chunks over time, usually two to three weeks, but, like you said, there is a longer time horizon spanning months, even years into the future, sometimes for those worthwhile, meaty things to be delivered that moves the strategic needle if I may use that buzzword. So, let's say we at that lean portfolio level, we're looking at epics, right, and Participatory Budgeting, we are looking at initiatives on an epic to epic basis per se, where would the Lean Startup Cycle come in here? So is it that Participatory Budgeting could be a mechanism that is used for assessing, okay, this is the MVP features that have been developed and all that, the leading indicators we've gotten, that's presented to the group, and on that basis, we make that pivot or persevere or stop decision, would that fit in? Luke Hohmann Yeah, so let's, I mean, you're close, but let me make a few turns and then it'll click better. First, let's acknowledge that the SAFe approach to the Lean Startup Cycle is not the Eric Ries approach, there are some differences, but let's separate how I fund something from how I evaluate something. So if I'm going to engage in the SAFe Lean Startup Cycle, part of that engagement is to fund an MVP, which is going to prove or disprove a given hypothesis. So that's an expenditure of money. Now there's, if you think about the expenditure of money, there's minimally two steps in this process - there's spending enough money to conduct the experiments, and if those experiments are true, making another commitment to spend money again, that I want to spend it. The reason this is important is, let's say I had three experiments running in parallel and I'm going to use easy round numbers for a large corporation. Let's say I want to run three experiments in parallel, and each experiment costs me a million pounds. Okay. So now let's say that the commercialisation of each of those is an additional amount of money. So the portfolio team sits around the table and says, we have the money, we're going to fund all three. Okay, great. Well, it's an unlikely circumstance, but let's say all three are successful. Well, this is like a venture capitalist, and I have a talk that I give that relates the funding cycle of a venture capitalist to the funding cycle of an LPM team. While it's unlikely, you could have all three become successful, and this is what I call an oversubscribed portfolio. I've got three great initiatives, but I can still only fund one or two of them, I still have to make the choice. Now, of course, I'm going to look at my economics and let's say out of the three initiatives that were successfully proven through their hypothesis, let's say one of them is just clearly not as economically attractive, for whatever reason. Okay, we get rid of that one, now, I've got two, and if I can only fund one of them, and the ROI, the hard ROI is roughly the same, that's when Participatory Budgeting really shines, because we can have those leaders come back into the room, and they can say, which choice do we want to make now? So the evaluative aspect of the MVP is the leading indicators and the results of the proving or disproving of the hypotheses. We separate that from the funding choices, which is where Participatory Budgeting and LPM kick in. Ula Ojiaku Okay. So you've separated the proving or disproving the hypothesis of the feature, some of the features that will probably make up an epic. And you're saying the funding, the decision to fund the epic in the first place is a different conversation. And you've likened it to Venture Capital funding rounds. Where do they connect? Because if they're separate, what's the connecting thread between the two? Luke Hohmann The connected thread is the portfolio process, right? The actual process is the mechanism where we're connecting these things. Ula Ojiaku OK, no, thanks for the portfolio process. But there is something you mentioned, ROI - Return On Investment. And sometimes when you're developing new products, you don't know, you have assumptions. And any ROI, sorry to put it this way, but you're really plucking figures from the air, you know, you're modelling, but there is no certainty because you could hit the mark or you could go way off the mark. So where does that innovation accounting coming into place, especially if it's a product that's yet to make contact with, you know, real life users, the customers. Luke Hohmann Well, let's go back to something you said earlier, and what you talked earlier about was the relationship that you have in market researching customer interaction. In making a forecast, let's go ahead and look at the notion of building a new product within a company, and this is again where the Agile community sometimes doesn't want to look at numbers or quote, unquote get dirty, but we have to, because if I'm going to look at building a new idea, or taking a new idea into a product, I have to have a forecast of its viability. Is it economically viable? Is it a good choice? So innovation accounting is a way to look at certain data, but before, I'm going to steal a page, a quote, from one of my friends, Jeff Patton. The most expensive way to figure this out is to actually build the product. So what can I do that's less expensive than building the product itself? I can still do market research, but maybe I wouldn't do an innovation game, maybe I'd do a formal survey and I use a price point testing mechanism like Van Westendorp Price Point Analysis, which is a series of questions that you ask to triangulate on acceptable price ranges. I can do competitive benchmarking for similar products and services. What are people offering right now in the market? Now that again, if the product is completely novel, doing competitive benchmarking can be really hard. Right now, there's so many people doing streaming that we look at the competitive market, but when Netflix first offered streaming and it was the first one, their best approach was what we call reference pricing, which is, I have a reference price for how much I pay for my DVDs that I'm getting in the mail, I'm going to base my streaming service kind of on the reference pricing of entertainment, although that's not entirely clear that that was the best way to go, because you could also base the reference price on what you're paying for a movie ticket and how many, but then you look at consumption, right, because movie tickets are expensive, so I only go to a movie maybe once every other month, whereas streaming is cheap and so I can change my demand curve by lowering my price. But this is why it's such a hard science is because we have this notion of these swirling factors. Getting specifically back to your question about the price point, I do have to do some market research before I go into the market to get some forecasting and some confidence, and research gives me more confidence, and of course, once I'm in the market, I'll know how effective my research matched the market reality. Maybe my research was misleading, and of course, there's some skill in designing research, as you know, to get answers that have high quality signal strength. Ula Ojiaku Thanks for clarifying. That makes perfect sense to me. Luke Hohmann It's kind of like a forecast saying, like there's a group of Agile people who will say, like, you shouldn't make forecasts. Well, I don't understand that because that's like saying, and people will say, well, I can't predict the future. Well, okay, I can't predict when I'm going to retire, but I'm planning to retire. I don't know the date of my exact retirement, but my wife and I are planning our retirement, and we're saving, we're making certain investment choices for our future, because we expect to have a future together. Now our kids are older than yours. My kids are now in university, and so we're closer to retirement. So what I dislike about the Agile community is people will sometimes say, well, I don't know the certainty of the event, therefore, I can't plan for it. But that's really daft, because there are many places in like, you may not for the listeners, her daughter is a little younger than my kids, but they will be going to university one day, and depending on where they go, that's a financial choice. So you could say, well, I don't know when she's going to university, and I can't predict what university she's going to go to, therefore I'm not going to save any money. Really? That doesn't make no sense. So I really get very upset when you have people in the agile community will say things like road mapping or forecasting is not Agile. It's entirely Agile. How you treat it is Agile or not Agile. Like when my child comes up to me and says, hey, you know about that going to university thing, I was thinking of taking a gap year. Okay, wait a minute, that's a change. That doesn't mean no, it means you're laughing, right? But that's a change. And so we respond to change, but we still have a plan. Ula Ojiaku It makes sense. So the reason, and I completely resonate with everything you said, the reason I raised that ROI and it not being known is that in some situations, people might be tempted to use it to game the budget allocation decision making process. That's why I said you would pluck the ROI. Luke Hohmann Okay, let's talk about that. We actually address this in our recent paper, but I'll give you my personal experience. You are vastly more likely to get bad behaviour on ROI analysis when you do not do Participatory Budgeting, because there's no social construct to prevent bad behaviour. If I'm sitting down at a table and that's virtual or physical, it doesn't matter, but let's take a perfect optimum size for a Participatory Budgeting group. Six people, let's say I'm a Director or a Senior Director in a company, and I'm sitting at a table and there's another Senior Director who's a peer, maybe there's a VP, maybe there's a person from engineering, maybe there's a person from sales and we've got this mix of people and I'm sitting at that table. I am not incented to come in with an inflated ROI because those people are really intelligent and given enough time, they're not going to support my initiative because I'm fibbing, I'm lying. And I have a phrase for this, it's when ROI becomes RO-lie that it's dangerous. And so when I'm sitting at that table, what we find consistently, and one of the clients that we did a fair amount of Participatory Budgeting for years ago with Cisco, what we found was the leaders at Cisco were creating tighter, more believable, and more defensible economic projections, precisely because they knew that they were going to be sitting with their peers, and it didn't matter. It can go both ways. Sometimes people will overestimate the ROI or they underestimate the cost. Same outcome, right? I'm going to overestimate the benefit, and people would be like, yeah, I don't think you can build that product with three teams. You're going to need five or six teams and people go, oh, I can get it done with, you know, 20 people. Yeah, I don't think so, because two years ago, we built this product. It's very similar, and, you know, we thought we could get it done with 20 people and we couldn't. We really needed, you know, a bigger group. So you see the social construct creating a more believable set of results because people come to the Participatory Budgeting session knowing that their peers are in the room. And of course, we think we're smart, so our peers are as smart as we are, we're all smart people, and therefore, the social construct of Participatory Budgeting quite literally creates a better input, which creates a better output. Ula Ojiaku That makes sense, definitely. Thanks for sharing that. I've found that very, very insightful and something I can easily apply. The reasoning behind it, the social pressure, quote unquote, knowing that you're not just going to put the paper forward but you'd have to defend it in a credible, believable way make sense. So just to wrap up now, what books have you found yourself recommending to people the most, and why? Luke Hohmann It's so funny, I get yelled at by my wife for how many books I buy. She'll go like “It's Amazon again. Another book. You know, there's this thing called the library.” Ula Ojiaku You should do Participatory Budgeting for your books then sounds like, sorry. Luke Hohmann No, no, I don't, I'd lose. Gosh, I love so many books. So there's a few books that I consider to be my go-to references and my go-to classics, but I also recommend that people re-read books and sometimes I recommend re-reading books is because you're a different person, and as you age and as you grow and you see things differently and in fact, I'm right now re-reading and of course it goes faster, but I'm re-reading the original Extreme Programming Explained by Kent Beck, a fantastic book. I just finished reading a few new books, but let me let me give you a couple of classics that I think everyone in our field should read and why they should read them. I think everyone should read The Mythical Man-Month by Fred Brooks because he really covers some very profound truths that haven't changed, things like Brooks Law, which is adding programmers to a late project, makes it later. He talks about the structure of teams and how to scale before scaling was big and important and cool. He talks about communication and conceptual integrity and the role of the architect. The other book that I'm going to give, which I hope is different than any book that anyone has ever given you, because it's one of my absolute favourite books and I give them away, is a book called Understanding Comics by Scott McCloud. Comics or graphic novels are an important medium for communication, and when we talk about storytelling and we talk about how to frame information and how to present information, understanding comics is profoundly insightful in terms of how to present, share, show information. A lot of times I think we make things harder than they should be. So when I'm working with executives and some of the clients that I work with personally, when we talk about our epics, we actually will tell stories about the hero's journey and we actually hire comic book artists to help the executives tell their story in a comic form or in a graphic novel form. So I absolutely love understanding comics. I think that that's really a profound book. Of course you mentioned Alex Osterwalder's books, Business Model Generation, Business Model Canvas. Those are fantastic books for Product Managers. I also, just looking at my own bookshelves, of course, Innovation Games for PMs, of course Software Profit Streams because we have to figure out how to create sustainability, but in reality there's so many books that we love and that we share and that we grow together when we're sharing books and I'll add one thing. Please don't only limit your books to technical books. We're humans too. I recently, this week and what I mean recent I mean literally this weekend I was visiting one of my kids in Vermont all the way across the country, and so on the plane ride I finished two books, one was a very profound and deeply written book called Ponyboy. And then another one was a very famous book on a woman protagonist who's successful in the 60s, Lessons in Chemistry, which is a new book that's out, and it was a super fun light read, some interesting lessons of course, because there's always lessons in books, and now if it's okay if I'm not overstepping my boundaries, what would be a book that you'd like me to read? I love to add books to my list. Ula Ojiaku Oh my gosh, I didn't know. You are the first guest ever who's twisted this on me, but I tend to read multiple books at a time. Luke Hohmann Only two. Ula Ojiaku Yeah, so, and I kind of switch, maybe put some on my bedside and you know there's some on my Kindle and in the car, just depending. So I'm reading multiple books at a time, but based on what you've said the one that comes to mind is the new book by Oprah Winfrey and it's titled What Happened to You? Understanding Trauma, because like you said, it's not just about reading technical books and we're human beings and we find out that people behave probably sometimes in ways that are different to us, and it's not about saying what's wrong with you, because there is a story that we might not have been privy to, you know, in terms of their childhood, how they grew up, which affected their worldview and how they are acting, so things don't just suddenly happen. And the question that we have been asked and we sometimes ask of people, and for me, I'm reading it from a parent's perspective because I understand that even more so that my actions, my choices, they play a huge, you know, part in shaping my children. So it's not saying what's wrong with you? You say, you know, what happened to you? And it traces back to, based on research, because she wrote it with a renowned psychologist, I don't know his field but a renowned psychologist, so neuroscience-based psychological research on human beings, attachment theory and all that, just showing how early childhood experiences, even as early as maybe a few months old, tend to affect people well into adulthood. So that would be my recommendation. Luke Hohmann Thank you so much. That's a gift. Ula Ojiaku Thank you. You're the first person to ask me. So, my pleasure. So, before we go to the final words, where can the audience find you, because you have a wealth of knowledge, a wealth of experience, and I am sure that people would want to get in touch with you, so how can they do this please? Luke Hohmann Yeah, well, they can get me on LinkedIn and they can find me at Applied Frameworks. I tell you, I teach classes that are known to be very profound because we always reserve, myself and the instructors at Applied Frameworks, we have very strong commitments to reserving class time for what we call the parking lot or the ask me anything question, which are many times after I've covered the core material in the class, having the opportunity to really frame how to apply something is really important. So I would definitely encourage people to take one of my classes because you'll not get the material, you'll get the reasons behind the material, which means you can apply it, but you'll also be able to ask us questions and our commitment as a company is you can ask us anything and if we don't know the answer, we'll help you find it. We'll help you find the expert or the person that you need talk to, to help you out and be successful. And then, and I think in terms of final words, I will simply ask people to remember that we get to work in the most amazing field building things for other people and it's joyful work, and we, one of my phrases is you're not doing Agile, if you're not having fun at work, there's something really wrong, there's something missing, yeah we need to retrospect and we need to improve and we need to reflect and all those important things, absolutely, but we should allow ourselves to experience the joy of serving others and being of service and building things that matter. Ula Ojiaku I love the concept of joyful Agile and getting joy in building things that matter, serving people and may I add also working together with amazing people, and for me it's been a joyful conversation with you, Luke, I really appreciate you making the time, I am definitely richer and more enlightened as a result of this conversation, so thank you so much once more. Luke Hohmann Thank you so much for having me here, thank you everyone for listening with us. Ula Ojiaku  My pleasure. That's all we have for now. Thanks for listening. If you liked this show, do subscribe at www.agileinnovationleaders.com or your favourite podcast provider. Also share with friends and do leave a review on iTunes. This would help others find this show. I'd also love to hear from you, so please drop me an email at ula@agileinnovationleaders.com Take care and God bless!   

In this episode of the Engineering Room, Dave Farley and Kent Beck have a wide-ranging discussion about the return of waterfall development in software, TDD, Software Design and lots of other things along the way. Kent Beck is the first signatory of the Agile Manifesto. He is the author of the industry-changing book "Extreme Programming Explained". Kent popularised Continuous Integration and TDD and wrote the first version of xUnit, the unit testing framework that has informed the design of unit testing frameworks ever since. It is hard to imagine people who aren't familiar with Kent Beck's work, but even if that is the case, his work has had an impact on how you think about, and practice software development and software engineering.xx⭐ PATREON: Join the Continuous Delivery community and access extra perks & content! ➡️ https://bit.ly/ContinuousDeliveryPatreon

Konstantin Ribel: Rebuilding Scrum Team Dynamics To Overcome Remote Work Anti-Patterns Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Konstantin recounts a team's struggle rooted in prioritizing individual tasks over collective effort. Daily meetings centered on status updates fostered a fragmented and siloed work environment. The team working remote made the issue even worse, making it hard to have face-to-face interaction and pair-working. All of these patterns resulted in underperformance. Konstantin advises regular team gatherings, emphasizing the importance of on-site collaboration. He underscores the human element, urging teams to function cohesively as people. Featured Book Of The Week: The Miracle Morning by Hal Erold In this segment, Konstantin delves into how his morning routine, inspired by "The Miracle Morning," by Hal Erold has profoundly influenced his role as a Scrum Master. He emphasizes the critical link between personal and professional development, crediting the book "Extreme Programming Explained" for its condensed wisdom. Konstantin highlights Kent Beck's mantra of "do more of what works" and expresses a preference for pair working, acknowledging its occasional impracticality. He consistently applies the insights gained from this book, advocating against the anti-pattern of delayed feedback in his work with teams.   [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!     About Konstantin Ribel Konstantin drives organizational success through innovative thinking, simplifying processes, and building high-performing teams. With a strong track record in change management and process optimization, he leads agile transformations and applies systems thinking for adaptable, thriving businesses in dynamic industries. You can link with Konstantin Ribel on LinkedIn. 

Transcript: Joe Krebs 0:10 Agile FM radio for the Agile community, www agile.fm. Welcome thanks for tuning in to another episode of agile FM today I have Jacopo Romei if I pronounced that correctly with me, based out of Torino in Italy. And he is my guest today got to speak about a topic today. It's called extreme contracts he published about this or long, long time ago in Italian. And just recently in 2023, he also finished his English version of his book, extreme contracts. So that's all available. He is also available at his domain name, Jacopo Romei.com. And we will also spell that out on the Show page. So people can just click on the website, as well as the three chapters of the book that will be available on the on the show page. But first and foremost, welcome to the podcast.Jacopo Romei 1:15 Ciao. Hi, how are you?Joe Krebs 1:18 I'm doing great. How are you?Jacopo Romei 1:21 I'm quite good, quite good. Just a reference. My name is can be pronounced your from Germany and you can pronounce it very easily. Jacobo, the J is Ja!Joe Krebs 1:31 Yah, cool. Boy, it is okay. Thank you. Thanks for clarifying. And it is important, right? So sorry about that. Extreme contracts is a word extreme in it. People in the Agile community familiar with extreme programming, maybe the first thing that would stand out is the word extreme. It's like, how does this relate? Why is it extreme? And why contracts? What's so special about contracts, I picked up a YouTube talk from you about extreme contracts, you're very passionate about contracting, work, and we just want to touch base on on that topic. So what's so different about extreme contracts versus regular contracts? Jacopo Romei 2:10 So, u m, I've been a developer since 1996. And I've been an entrepreneur in IT. And then along the years, I shifted to where the broader range of knowledge work. Okay, so let's not to get too much into the details of my job. But and what I noticed when I was doing my intrapreneurial experience is that the commonly used contracts, were somehow capping the maximum performance of my companies, organizations and teams, and even I didn't do as an individual. And so I started experimenting with different and non ordinary ways to negotiate my agreements. And so I mean, I just asked myself, well, what if I could shape a contract from scratch the way I really wanted it to work and support my collaborations with my customers and providers. After a few years experimenting, I started in 2010. And then I realized that there were common principles among the most successful contracts and agreements that I made. And so since I was a very, I still am a very huge fan of Ken Beck's work, Extreme Programming Explained. Actually, I just decided to, to think in somehow in similar analogous terms, so basically, what the word extreme and extreme programming means, what if we bring everything that works every principle and every practice that seems to work? To the extreme? So what if we go from back in the time it was like from two years releases to one month releases? So what if we bring them to one weekly releases or daily releases? Okay, what, what if we go from one to 10? If we go to 11? Right, so I thought the same with negotiating contracts for digital work. And it worked, actually, after a few experiments that, that of the building upon I decided to, I needed a brand actually, I needed a name to, to name the, the group of principals. And so I decided to go for extreme contracts, who was actually that's what they are.Joe Krebs 4:31 Yeah. And we want to definitely explore maybe one or two of those principles, if it see how far we're getting. But one thing that really stood out in your talk about extreme contracts in the first place, I think that was very deep as contracts are because there there because of a lack of trust.Jacopo Romei 4:49 Yeah. I mean, I mean, after so many years, I still strongly strongly believe it. So basically, so what what What's the reasoning behind contract? So, we have to start working together. And we have to know whether you will be delivering you will deliver if you have to know whether our pay or not. So we have doubts, okay, we have fears, we are afraid that we will not be behaving correctly, right. And this fear, the fear of someone else not behaving correctly is called lack of trust. Okay, there is another name. And so contracts are basically a way to surrogate that trust into a piece of paper back in time or in an in an email or in a blockchain based device. And I don't want to get into the smart contracting part, it's not the topic for today. But contracts are a way by which we substitute trust with something that we hope will be enforceable in case things go wrong. And what I noticed along the years is that everybody everyone was had works with two groups of people, there is a bigger group of people we trust, and with which we don't need to send formal papers to sign agreements to be formal and discuss a lot the thing that we are going to do together, and there is another small group, usually made of new leads, that are asking us to, for long conversations, long calls, long video conferences, long email, much much information going back and forth. And actually, these two groups are also different for a long another dimension revenue. And actually, the most of our revenues come from the people we trust. And by the by which we are trusted. And I'm in. So I decided to create a set of principles, I decided to experiment with contracts, as I was saying before, to optimize the time, we require it it is required to build the trust that we need to go to shift the our leads from the first group, sorry, from the second group to the first one. So basically, how fast rather than optimizing contracts for failure recovery, so basically optimizing the contract for how well they will be protecting us in a court. So I prefer the contracts to be creating dynamics by which we go very fast to trust in each other. And in the end, eventually, maybe not even needing the contract. Joe Krebs 7:40 So this is why so this is very interesting. You're not saying that extreme contracts are no contracts at all anymore. Jacopo Romei 7:45 No. Joe Krebs 7:46 that's not what we're saying. Right? What you're saying it's, it's more about, like putting the right content together. And there was another thing that stood out in your work is that a waterfall agreement will never work for non waterfall process.Jacopo Romei 8:03 So I started carrying about it was 2003 the time in May, I started coding my first unit test. Okay, so I got into that. That's the day I I like to think as the my beginning in the Agile world, okay, cool. But after a few years, I realized that with my teams, or other teams, I even owned, we were we were going on discussing again, and again, the way we could improve our practices, our deployments, our bug tracking, our testing, and blah, blah. So all these technical end, even sometimes, even a bit. management practices, okay, like the stand up meeting, or the retrospectives and blah, blah, blah, but only know, every time in the end, we were required, required to deliver a fixed scope, with a fixed budget with a given quality that usually was not, there was never question which is absurd. And in a given then set deadline. And I mean, in the mean, thinking, I'm taught to think about the root causes of the problems. And when I investigated these problems, I ended up having often a problem with the contract with agreement with the expectations of the customer. And so I decided to fix that root cause, despite we can read in the Agile Manifesto that we should pray for collaboration rather than that rather than contract negotiation. But still, if contract negotiation is the roadblock for a proper collaboration, still, we have to fix thatJoe Krebs 9:45 right the scope, right? So when we're talking about scope off of any kind of effort, but isn't that like also based on your experience? Like I can only speak for myself here when working with clients? Isn't it also like a dilemma of business agility that we have have many flourishing product and IT organizations using agile and we have a very traditional procurement department. And when you work within these constraints, I mean legally bound, it is a legal document, you're signing it, and you're adhering to certain sections within your document. And if they are screaming waterfall, it is it is very hard to work this way. Because you do need to deliver, I would assume, right? You cannot just say like I signed a contract or now we'll work Agile is like it the contract itself might be in your way. But what's your experience with that?Jacopo Romei 10:31 I mean, our experience is probably quite common, I agree with you, usually Procurement Offices are a roadblock in the true agility of the of any development experience. Still, okay, so on one side, if I if I were the one who owns the company, the organization, the one who basically paid those procurement officers to, to, to provide for a better for a good selection of providers, I would be worried because actually, we are we have a part of an organization which is somehow hindering the performance of the of the overall performance of the organization they belong to. So if someone owning procurement, or paying for a procurement officers in Now in this podcast, please, please, please, please question their work. Because actually, it's absurd that the strategy of a company gets set by a part of the organization rather than from the, from the organization itself. Okay. On the on the other hand, from from the provider point of view, I think we have a few things to try. First, there is a chance not that I will start from the most radical, just to say that it's not the only one. Okay, so I want to get rid of the most radical approach, which is there. It's a it's an option, which is not working for corporation or for bad procurement officers. But that's, I mean, that's too easy. Someone I know, does it and they're thriving. So it's possible, it's doable, and we can all we could all agree to starve procurement offices, the way that procurement officers around the world, but I mean, this is not really stick. I'm pretty aware of it of this. On the other. Second option that we have is there is one principle among the extreme contracts principle, which is called chaos in small doses, okay. And one thing that I cared so much along these years was to craft principles that could be somehow picked up cherry picked and adapted to our context, so that everybody, in their own context might find a solution to improve their negotiation their agreement. In the procurement department space, one thing that I that I learned to use was the principle called chaos in small doses models, which basically mean being shipped crafting agreements that are short in time, even keeping all other vital variables intact. So basically, considering all the other details the same, we could just shorten the amount of time, money and basically risk that we are exposing ourselves to, and work with those procurement officers with traditional rules in a smaller in a smaller time and space. Someone might argue well, but that's very inefficient, you have to renegotiate every time and you have to negotiate quite often. On the other hand, in my experience, usually the procurement procurement practices that we hate are usually meant to scale in a repetition quite well, sexually, they have somehow Taylorist legacy Okay, heritage. So usually after the first time after the kickoff after the beginning, repeating a collaboration with a procurement officers that have already that has already met you, it's quite easier and you can renew the agreement quite easily. If you have a good agreement, if you have a strong bond with the real actual buyer within the organization, usually at that point, the second the third, the fourth collaboration, the procurement office will not be a problem anymore.Joe Krebs 14:46 Yeah. The very interesting that there would also be trust building I would assume starting in such small batches wide. You know, you go through a very small agreement, you get to know each other you work together. You're building a relationship with a procurement. And what's also fascinating about extreme contracts is that you really, you're highlighting already. I mean, we're in the Agile community, we're focusing on value, right? So it's all about value to be produced. And I think it's fascinating right now. It's, it's June 2023. Many people go back to work or have, you know, arrangements where they work certain hours at home, and it's more flexible since COVID. The workplace and even those things were like defined in the past, right? You will be having working hours and Monday to Friday. And in all of those things, and it is really, I think, what we're noticing when is it's a perfect example, it's about value, right? Where do you where do you produce the most value? Is it? Is it in your office? Is it in your environment? Or is it? Is it on the train? Or is it on a plane? Or is it at home? You know, where? Where can you produce the value, and I think if you are focusing on value, and it's one of your statements here is in you are actually free to focus on all of those things you would like to do like refactoring or unit testing, right? Because they're not, they're not part of of the contract anymore? You say you're focusing on value, but you're not focusing on the actual tasks to be performed? Faster? Yeah. Do you want to, you want to give a little context of why you came to that conclusion, which I think is great.Jacopo Romei 16:21 Okay, so once, three things First, the usually, professionals are not aware of the value they create. So this is a main topic we could discuss about only this topic for like hours and hours, and we won't, but I mean, the point is, I usually when I ask audiences in conferences, like hey, what do you sell code? And actually, it's amazing, because actually, if I, I mean, Joe, if I ask you, do you, would you like, Would you be more glad to receive from a 10 kilograms of gold or 100 kilograms of gold? And I'm pretty sure you will answer as a gift. He will answer one under kilograms. Okay, fine. No, for the same problem. For the same automation of a solution to a given problem, would you like to receive 10 lines of code, or 100 lines of code? Gold is an asset, while code is a liability. Okay. So basically, if if we provide the same value for more code with more code, actually, we are having a big, so a bigger problem maintaining the code, fixing bugs, and blah, blah, blah, okay, and this is true for mostly, most of knowledge work, everything we do usually is not the value that we're selling, the value that we're selling is the reason why people are paying for us. And so, okay, this is what this was the first point, second point, if we sell our time, like in time and material contracts, but even in fixed price, usually you you are estimating for the amount of days that you will be working for the customer, right, you end up selling the cost and not the value of your delivery. Which brings us to the third most critical point. If we sell our time, if I sell to my customer, my hours, they are entitled to question the way I spend my time. Just actually, that's why they are buying. And instead, if we want to sell the value the problem or the solution to their to their problems, actually, all of a sudden, we become free to use our time the way we want. Yeah, you will get more leads nice. It's gonna be a website or newsletter or temporary shop in the main town. Okay. Okay, fine. But the point is that if you get more leads, and I can prove that I brought more leads to you. Actually, that's enough. And if I want to write unit tests, if I want to write documentation, if I want to share the burden with many people, or just alone, it's my business. And I want to decouple my knowledge work from customer interest. As much as we all decouple the work that was needed to build our glasses, our cars, our pens, from the price and the value that we assign to those objects in our lives. I don't know how much my pen is. I know how much is worth. But I know how what was its cost when the producer made it, and no one questioned it. But that's the reason that's because we don't pay the time of the workers that made our washing machine. And instead, we as professionals, knowledge work professionals, we keep on selling our hours. So don't we shouldn't get surprised to be questioned the way we use our time.Joe Krebs 19:57 That's why early on is like this is where we're crossing from I think the word you said is professional, ethical, where the ethical example the software engineer, but I do want to go a little deeper on the liability thing you just mentioned, because I don't know if somebody might be listening to this and said, Oh, wow, we're 10 lines of code or 100 lines of code, do I really care? Do I really care if I get the value? And I would say you do care, right? Because you might have maintenance on 100 lines of code versus 10 lines of code, you could say, less is more, or maybe the 10 codes, the 10 lines of code might be very ugly and haven't been refactored. And nobody wants to touch that segment. So it's a liability, right. It's not like you can measure this in lines of code. And I think that is also an important point that I hope nobody's out there having a contract in places as you're writing 1000 lines of code every day. That will be that would be very sad.Jacopo Romei 20:47 I've heard a few actually, along the years, I've heard a few and not only in one country. I mean, it's, I've read about this in forums, like by the end of the 90s, or like 10 years ago, I mean, it was like people getting paid by the lines of code. But also, I mean, another objection that we might hear is a but there might be value in writing more lines of code, if they are more maintainable if they provide with a more elegant and clear structure. And I agree, obviously. But I mean, this is nitpicking, if you want to get the point that we're making here, dear listener, you can.Joe Krebs 21:31 This is awesome. Should we explore maybe another one? We already saw chaos in small doses. But but maybe maybe we do. skin in the game sounds very interesting. Maybe? Well, we'll take that as an example. And just to give people an exposure to that they can obviously read up on that in your book, extreme contracts, but skin in the game. I use that a lot myself, like for other references. How does that relate to extreme contracts?Speaker 2 21:59 Well, I'm okay. So the saying skin in the game is quite old, but I'm using it in the same with the same meaning and the same usage that I learned reading Nassim Taleb books, anti fragile, and the Black Swan, and even the book itself titled skin in the game. So I'm using skin in the game as a device to reduce risk in all situations. Okay, so the main, one basic example can be if I ask John to build a bridge, and then I asked him to sleep under the bridge, for the first two years after I think I've been built it, probably John will be induced will be given a positive incentive for the quality of the construction, and for somehow providing all that redundancy that gives us safety in life. Okay, we got two lungs, we got two eyes, we have two pilots on planes. And if we go with risking things in engineering, we should provide with options and ways and redundancy to to provide us with ways to the riskiest situations. Usually, when we have designers and programmers and professionals that have no skin in the game, they sell efficiency, which is somehow a way to over optimize things, because the reduction of cost can be sold quite easily. Okay. So, for example, so if we asked John to build the bridge, and then we don't ask him to live under the bridge for two years, he might give us like, an experimental shape, or an experimental design new materials that have not been tested by centuries, and so on. And once in a while, I mean, I'm thinking about the city of Genoa, in Italy, where there was a huge bridge that fell down. I mean, yeah, I mean, the skin of the people in the game is a way by which we can induce a different landscape of rate. Okay, so let me be more concrete because actually, what I'm not saying that John would be somehow militious somehow trying to to game us, okay. But what I'm saying is that our systemic prudence kicks in when we ask people to respond for their their actions. On the other side, we want people to enjoy the results of work they do above expectations. Yeah. So that they have double incentive to perform is actually the problem. So one other suspicion of lack of skin in the game is usually that when I deliver late, I am punished some way one way or another, you can even be dissatisfaction mail. Okay. Right. When I deliver earlier, usually, I don't get any prize. And so I mean, this basically creates no incentive for me to deliver before the deadline. I'm only I'm only having an incentive to on time. Yeah, exactly. So which literally means slightly late, because there is not on time. So okay, so, and skin in the game is the thing that should be reflected in our agreements, I think people working together on anything should be enjoying benefits for over delivering, they don't have to be equal, but they have to be in the same direction. So basically, it's it's like, I mean, for the nerdiest out there, it's I would say that the vector is the point in the same direction but not having the same magnitude. And all the people involved should suffer a little bit of pain if things go worse then then planned that's usually usually usually especially in corporation, we have very huge asymmetry in which people deciding things are able to go away with short term advantages short term benefits and leaving the the mid-term, long-term harm suffered by someone else who was forced to be there, right, which is I mean, from an organization point of view, there is increasing the risk of failure and bankruptcy or failure in generalJoe Krebs 26:50 is a perfect example for a lack of skin in the game like for many offshore contracts, where the whole product was being outsourced offshored onshored, nearshored, whatever whatever it is, by the model, it is basically like delegating everything, but being in control of saying, Are you shipping the right product, which is obviously in a model like that extremely challenging, but also not having any skin in the game? If I if I assess this correct.Speaker 2 27:17 let me give let me bring this point even further, we can say that traditional contracts have complete lack of skin in the game because fixes I mean, I would traditional contracts, I mean, or either fixed price contracts or timing material contracts, okay, I know there are many variation varieties, but basically, these are the two main, like, most of the contracts fall into these two categories. Both these categories of contract lack skin in the game, because in a fixed price contract, actually, the customer is shifting all the burden on the provider, if everything anything goes wrong, for any reason, even systemic reasons, okay. The provider, the supplier has to work past the deadline, which basically means this is nice, because it basically it means working for free, unless you plan for a buffer, which is basically planning for, for stealing money if everything goes fine. I mean, this this, this breaks my head. Yeah, in, in the case of timing material contracts, on the other hand, the risk is completely shifted on the other side, and if anything goes not as planned for any reason. And I mean, we started thinking it might be over in 10 days, and then it requires 20 days. I mean, who cares? The customer is going to pay. I mean, this is not exactly the tone. I expect when we are talking about skin in the game. Joe Krebs 28:49 That is not going to create a healthy customer relationship, right, either. If you're thinking about trust again, right, where we started with our podcasts whereJacopo Romei 29:00 we all go back to the way we try to build trust and the way our contract usually erode our trust. Yeah, that's, that's, that's completely crazy how we can I mean, many people might say, Well, yeah, but it's this is normal. I mean, it's so common, but normal is is a word with two meaning normal is somehow means frequent. But normal also means just right. Okay. And I don't think contracts which are not normal, should be normal.Joe Krebs 29:32 That is awesome. Jacopo, now, yes, here we go. I want to say thank you for spending a few minutes here with me and talking about extreme contracts. I am super thrilled to bring this topic to Agile FM listeners, I think it's really, I mean, a lot of people probably look at templates and documents and contracts, etc. And you're like, maybe something's wrong with that, but I think I feel like an episode of like this and hearing it from you. And obviously you're publishing about this and as I said, beginning to our chapters available on agile FM link there. So you can just go in and start reading for at least three chapters. There is a bigger book in the making. So maybe we'll that's the starting point for, you know, changing the, you know, future DNA of contracts within organizations and obviously, focusing on value. Great name of it too obviously, resonates very well with the Agile community catchy. Thank you for making it and being so passionate about it. Thank you so much.Jacopo Romei 30:35 My pleasure. Thanks to you.Joe Krebs 30:38 Thank you for listening to Agile FM, the radio for the Agile community. I'm your host Joe Krebs. If you're interested in more programming and additional podcasts, please go to www.agile.fm. Talk to you soon.

In today's episode I'm joined by J. B. Rainsberger for an assessment of what value can be derived from using ChatGPT as a programming tool. We also discuss why you should write your tests backwards, using ChatGPT to make tests pass, and J. B.'s philosophy and approach as a consultant.  Finally, we get into the benefits of joining J. B.'s JBrains Experience mentoring group.Extreme Programming Explained by Kent BeckExtreme Programming Installed by Ron Jeffries, Ann Anderson, and Chet HendricksonPlanning Extreme Programming by Kent Beck and Martin FowlerSwitch by Chip and Dan HeathTest Driven Development at Wiki.C2.comJBrains.ca - J.B. Rainsberger's SiteThe JBrains ExperienceThe Code WhispererBlog.JBrains.caThe World's Best Intro to TDD, Level 1J. B. Rainsberger on Twitter

Johannes Lindman: Lessons in Communication and Trust for Scrum Masters, helping teams overcome adversity Read the full Show Notes and search through the world's largest audio library on Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. In this episode, Johannes Lindman shares a story about a small team he worked with for a few months leading up to a major release. The team was focused on delivery and even had checklists to ensure that they were well-prepared. However, they encountered a problem that they had not anticipated and had to stop and acknowledge their failure. The team was surprised because they believed they had prepared well and were not sure how they missed the issue. The team started to point fingers and look at one person who did not talk much. They realized that they were not talking about the problems they were afraid of and needed to be super honest with each other. Johannes notes that the team trusted each other as individuals, but they did not pick up on each other's signs. In the end, the team learned the importance of communication, honesty, and trust. They realized that they needed to work on their communication skills and ensure that everyone felt comfortable speaking up when there was an issue. Featured Book of the Week: Extreme Programming Explained by Kent Beck In this segment, Johannes shares the impact that the book "Extreme Programming Explained" by Kent Beck had on his career. Johannes explains that the book helped him in many ways, and he found so many valuable ideas in it. He recalls the mantra  "make it work, make it right, make it fast," which he believes summarizes the essence of the book's philosophy. He credits the book with helping him to become a better developer and to embrace a growth mindset.  [IMAGE HERE] Do you wish you had decades of experience? Learn from the Best Scrum Masters In The World, Today! The Tips from the Trenches - Scrum Master edition audiobook includes hours of audio interviews with SM's that have decades of experience: from Mike Cohn to Linda Rising, Christopher Avery, and many more. Super-experienced Scrum Masters share their hard-earned lessons with you. Learn those today, make your teams awesome!   About Johannes Lindman Despite many years of experience Johannes still learns new things every day in order to stay relevant. This aligns with his curiosity on life and people.  You can link with Johannes Lindman on LinkedIn.

As we continue to learn from the XP book, Extreme Programming Explained, today we discuss what it means for software systems to go sour and how to prevent this from happening. We talk about what happens when the cost of making changes or defects rises so much that the system must be replaced and how XP creates and maintains a comprehensive suite of tests to counteract this risk. Tune in to learn more about how pair programming can help prevent the system from going sour, what to do when you are writing legacy code, the types of tests you should write and focus on, and so much more!

Let's talk about Agile! What is it, what do we like, we do we not like? In this episode, Steph and Chris discuss: Broadly, are they fans? What makes this practice work well? What makes this practice work poorly? And also, hit specific topics and practices like Scrum, Kanban, and Extreme Programming. Twitter Poll re: Gotime Podcast - Is Agile's Time Over? (https://twitter.com/gotimefm/status/1388126124299878412?s=21) The Mortifying Ordeal of Pairing All Day (https://www.simplermachines.com/the-mortifying-ordeal-of-pairing-all-day/) The Real Story Behind Story Points (https://thoughtbot.com/blog/the-real-story-behind-story-points) Agile Manifesto (https://agilemanifesto.org/) & Agile Manifesto -- Principles (https://agilemanifesto.org/principles.html) Extreme Programming Introduction (http://www.extremeprogramming.org/index.html) Extreme Programming Explained (https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/) Ron Jeffries - What is Extreme Programming (https://ronjeffries.com/xprog/what-is-extreme-programming/) Transcript: CHRIS: I feel like we should try a couple of different byes just so we have sort of a smorgasbord of options, and then we can pick the best one. STEPH: With countdowns, [laughter] because I do so well with countdowns. CHRIS: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Chris Toomey. STEPH: And I'm Steph Viccari. CHRIS: And together, we're here to share a bit of what we've learned along the way. So, Steph, I thought we would try maybe something a little bit different this week, a little bit more of a structured topic. In particular, I've been gathering little tidbits of information. I've been seeing conversations happen all around the topic of Agile, things that people like about Agile, things that people hate, mostly it's things that people hate about Agile. Lots of ire on the internet about Agile, but I think also some disagreement about what it actually means. And I think; generally, you and I are probably fans, so I want to talk about that. What parts do we like? What parts do we not like? What do we think Agile actually means or, at its best, maybe what it means? But yeah, let's start at the very top stuff. Steph, what do you think about Agile? STEPH: I am generally a fan. I'm with you. And yeah, the internet being full of more negative remarks and ire, that sounds very true. But generally, I am very much a fan of Agile, and the very broad scope of this is how we work, and this is how we plan our work, and this is how we collaborate as a team, and then how we reflect on the work that we have completed. I can also pick apart some of the things I don't like about Agile, but in the broad umbrella definition, I'm a big fan. I've enjoyed that approach. Granted, I've also only ever used Agile. I haven't written software using a Waterfall style, at least not purposefully. And then if I have encountered a team that was using more of a Waterfall style, then we changed it quickly. I really only have known the more Agile approach to writing software. CHRIS: I think that's largely true of me as well, where most of my work would fit somewhere under the umbrella of lowercase "a" agile, although I've tried variants of Scrum and Kanban and a bunch of other things that we'll probably chat about today. But I think in general, I find that things are most effective; things seem to move the most smoothly. And I think the software that we come out with is the best one. It's closest to those very simple ideals of Agile. And every layer of process that gets added on even though, like you, I've not done true Waterfall where it's like six months requirements gathering and then it gets handed off, and no one talks for a while. I've never done that. STEPH: I have to interject because I actually think you have in a previous life when you were an engineer. You have done the more Waterfall. Like, you have to plan very far in advance. CHRIS: I think this is one of those cases where people think "engineering" quote, unquote like mechanical engineering is one thing and it's actually...there is a little more structure, and there's a little more necessity of sequencing where you've got to figure out what you need to buy first because sometimes it takes a while to find the particular piece of metal that you need in the world. But it also has a lot of figuring out as you go and being like, well, we've got a bunch of stuff, and we're just going to figure it out. And also, this is something that as I was studying software while working as a mechanical engineer, I started to hear about this whole Agile thing, and I was like, huh, I wonder how I can bring more of that? Because I definitely saw cases where a more Waterfall-centric approach to engineering projects was leading to bad outcomes. It's like we decided upfront what we're going to do, and then we went away for six months, and we did it. And then we came back, and it turned out it was wrong. So that was solvable along the way. There were ways to build prototypes and things like that. So that is definitely a part of the mechanical engineering world. Although I think there are some true constraints, but I think there are also some occasionally self-imposed constraints, but again, I see sort of the same thing in software. Anytime that we can shorten feedback loops, that's what I like. And I think that for me, that's the core of Agile. Specifically, to come to the Agile Manifesto, to start at the very top, the thing that kicked it all off is a very simple document that the first line of it is "We prioritize individuals and interactions over processes and tools." It's like, yeah, that seems like a great thing, having more regular conversations about the things that we're building rather than having those initial conversations. And everybody goes away for a while and tries to build that thing, and then they come back, and hopefully, the thing that they've produced actually solves the problem. But I think almost always there are some deviations like, oh, actually, it would have been better if it was like this or now that we're actually trying it in the field, it's fundamentally different. So in that way, I think there's actually a lot of commonality between mechanical engineering and software development. STEPH: Okay, that makes sense. Yeah, I was thinking around the process of where you'd have to order stuff in advance versus for us; we can describe everything that we need as we need it unless we're having to procure some specific software or licensing. But otherwise, we don't have to wait on that shipment flow to then have our goods. And then, if we also mess something up, then we don't have to reorder more pieces. But I like how you started talking about that agile with lowercase "a" and then talking about the manifesto because I suspect most people are familiar with Agile, but it wouldn't hurt just to read off some of those top things about what Agile is so that way we're all on the same page together for this conversation. So you already covered the first one that talks about individuals and interactions over processes and tools, and then the others are working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. And that's it; those are the aspects of Agile. And so then, circling back to what you were saying earlier where people are having more criticisms around Agile, it sounds that it's less about Agile, and it's often more about the implementation of these ideas and then how you're approaching them. Because, boy, do we have several ways to implement Agile. We have Scrum; we have Kanban; there's Extreme Programming. Does that fall within the Agile umbrella? I think it does. CHRIS: I believe so. And I think a lot of the things that people take issue with particularly come from Scrum and Extreme Programming. We're taken to their extremes. Yeah, it's right there in the name, so you should probably know that it's going to be a little out there. But taken to the extreme and especially where it becomes rigid and dogmatic, then it becomes a problem. But again, so we listed out now the four items that are the core of the manifesto. There is a separate part of the manifesto, which is the principles, which digs in a little bit deeper, but it's still very much in that same ethos. But I do want to highlight because there's a subtext to the Agile Manifesto that I really love, which is given there are things on the left and then things on the right when the Agile Manifesto was presented. And so it's like we like individuals and interactions, that's the thing on the left, over processes and tools. And so the subtext below it is that is while there is value in the items on the right, we value the items on the left more. And that's one of the things that I love about the Agile Manifesto is it's not this very rigid thing that says, "This is good, and that is bad," it is a statement of a preference of well, yeah, it's definitely good to have comprehensive documentation. That's a really nice thing to have, but it's incredibly difficult. And if we have to choose, we're going to choose working software. We're going to prioritize that well before we have comprehensive documentation. So I really love the juxtaposition, and the emphasis on it's not that one is good and one is bad of these two things that we're comparing but that we have a preference, and that we want to orient our work around the items on the left rather than the items on the right, which I think the items on the right are more traditional or were more traditional to the Waterfall approach. STEPH: I like how you highlighted how those statements are presented to the reader. So then that way, as you mentioned, we still value what's on the right, but we favor more what's on the left. So one of the things that I saw recently was something that you shared with me in regards to where you're bringing up the idea of, like, hey, let's talk about Agile. And you shared with me a clip or a specific tweet that linked to a clip from the Go Time Podcast, which is a podcast that I hadn't listened to before. But I listened to that episode or at least part of it, and it's really delightful. I enjoyed listening to them very much. And they had Kris Brandow on the episode. And at the end of the episode...and they do something really fun where they ask the guests, "Do you have an unpopular opinion that you'd like to share?" And one thing that I like about their unpopular opinions is they often have polls afterwards, and they want to see was this truly an unpopular opinion? And if most people agree with you, then they actually consider it nope, he didn't win. I don't know if they use the word win if you didn't achieve the unpopular opinion. And in this instance, Kris shared the opinion that Agile is done and over with and that we should move on, which is a big thing to say. Everyone on the podcast reacted in a similar way that I would where it's like, well, how do we track things? And there are still things that we need to care about. But then also, there's a part of me that's just like, yes. I am not sure where Kris has heard it just yet when I heard that, but I'm already tuned in and very interested. And one of the things that Kris said that also really resonated with me is he mentioned that "I've never worked on a team where Scrum specifically like sprint and story points functions well," and I absolutely agree. There are parts of Scrum, we can get to the specifics that I think are fine that I've certainly used in the past and that have worked. Story points resonate deeply. I very much agree that story points are something that I do not enjoy using, and I do not find that they really lead to building software. There's even a blog post that I published along with Matt Sumner, a former thoughtboter and guest on this show, where we talk specifically about story points and some of the concerns and issues that we have with using story points. CHRIS: It was actually also the first episode where you came on as a guest to Bike Shed; that that was the topic that we dove into because it was so near and dear to our respective hearts. STEPH: That's right. I forgot about that. So yeah, story points are certainly up there on my don't list. I feel like we're doing a fashion do and don't, but we're doing the Agile do and don't list. [laughs] CHRIS: I kind of like that. Yeah, we should lean into that vibe. But yeah, continuing on with the poll there, it was interesting to see also, like you said, they tweeted out, and then there's the poll that comes after. And it was 64-ish percent of folks agreed that Agile's time is over and done with, and we need to move. Granted, it wasn't a huge sample size. It was like 85 people that took the poll but still, seeing both the statement and then also the general support from folks on the Twitter, it was interesting to see. So I do have the question of like, well, okay, if not, what else? And I share your sentiment of we should be able to ask questions and iterate. And nothing is so precious that it can't be replaced by something else that's better. So we always need to be trying to find the best ways to work. But again, I think there are still kernels of good stuff in the Agile. So I found this and I was like, oh, this is interesting. What's going on here? STEPH: So I'd love to dive into some of the specifics around Agile to understand what are the bits and pieces that work for you and the bits and pieces that don't. So if we are taking our Agile approach and reviewing the things that do and don't work and changing that process, what are the things that you would keep, and what are the things that you would throw out? CHRIS: Yeah, well, we can dig in, and we can bounce back and forth, I think, on this. But again, there are sort of a few different camps. So I collected together some of the lists of practices associated with some of the different approaches to Agile. So starting with Scrum, which I think perhaps is one of the most rigid, most structured, and perhaps most ire-deserving of the approaches to Agile, one of the first things is sprints or iterations, so the idea of starting...before you begin the work, you sit down, you define how much work you think you're going to take on. There's often an estimation process. Actually, we'll say that because that's maybe a separate idea, but even just broadly the idea of sprints and iterations, which often involve the idea of committing to a certain body of work. And that commitment is always handwavy and loose. No, no, no, we won't hold you to it, but then it's a constraint that's placed on the team. It's an expectation that's set, but it's wildly difficult to estimate software, as we all know. So sprints and iterations, personally, I am not a fan of. I really like a more continuous flow where we're constantly reprioritizing the work to be done. We're constantly measuring against what we built, what we think we need to get out there. How can we get something out in front of users as quickly as possible? But I've not found a ton of utility in the sprint or iteration workflow. But what do you think of that one? STEPH: Yeah, I'm generally not a fan of sprints, and it has taken me a while to get there. And I feel like I can admit that openly because it is something that I feel like when I first started doing software development, sprints were life. It was how you planned everything. It was how you committed to work. It's how you measured your work. It's how you then looked back to see what you could and couldn't accomplish in two weeks' time or maybe a week's time, depending on how long your sprint is. But over time, I have realized that I don't like the mentality of sprinting, and that may just be a nitpick on my part, but that is something that I don't enjoy because we write better software when we have breaks. And with the sprint methodology, there's really never that break unless you're going to plan that into your sprint. And then there's the idea of the upfront commitment, as you'd mentioned, it's one of those, don't worry, we're not going to hold you to this, but can we all commit to this work? And it's one of those you just feel compelled to say, "Yes," to the person who's asking because then you feel like a jerk if you push back and you say, "Well, actually, I don't know if I can, so I'm going to commit to way less." And then that's the approach that I started taking of, well, I don't know. So I'm going to always commit to a little bit because I'd rather overachieve and then deliver more than come in under because I could work really hard, but I've over-committed and then still feel like I didn't reach my goals, and that's a rough feeling. So I found that I was already lowering my commitment there. So then, it felt more appropriate to be in line with that sort of continuous workflow instead of trying to commit to all these features or all these tickets that needed to get done. I think those are the two areas for sprint where it doesn't align with me and where it can work for teams. But I feel like there's always that underlining unhappiness that a lot of us just don't want to talk about because we don't know what else to do other than to keep sprinting. CHRIS: Yeah, I think you said something about the specific, like nitpicking the word sprint, but I do think that's actually meaningful. It's The Bike Shed, after all; if we're not going to Bike Shed about some words, what are we doing here? But I do think that we're using that word...it's obviously the wrong word; this thing's a marathon. You can't have 26 2-week sprints back to back throughout a year. That's not going to work. That's not how humans work. But any amount that we let that thinking into our head, I think, is problematic. If I'm understanding correctly, it sounds like you've come to a place of comfort around committing to a smaller body of work and then ideally overdelivering. But in my experience, many developers, perhaps even most developers, don't feel comfortable. It's so difficult to say, "Yeah, I know that the login form should take a day. That's what I feel in my heart. But let's be honest, every other time we've done a form, it's taken a week. So I'm going to say a week." It's so hard to do that. And so I think continuously, we end up in a mode where we are failing to meet the collective commitment that we made, and that's demoralizing. That's going to constantly just be a drag on the team, even if they're fake, made-up deadlines that we're constantly setting, that we're constantly not hitting. Just doing that over and over, I think, is really detrimental to the morale of the team, to the cohesions, and the feelings of are we actually doing this work? So perhaps pedantic, but I definitely share all of that. STEPH: I do want to highlight, as I mentioned earlier, I'm feeling more comfortable that I can under commit and then I can overdeliver, and that is hard. That is something that still in the moment, even today, is very hard for me to do. And it's like how you said, in my heart, I feel like this should take a day, and the heart lies. But on top of that, it's often it's also my ego that's driving me all the time. And with that, it feels like a competitive environment to me where someone's saying, "Hey, can you get this done?" And in the moment, that brings out my more competitive side where I want to say, "Yes, I can get all this done, and I can deliver all the things." When, in truth, that's often not how it's going to work out. There is one thing I do like about sprints that I want to reflect on, or perhaps it's actually two. And one of them is that we are getting together every so often, and we're agreeing on the important work to be done. And I really like that planning process that is typically coupled with a sprint. So you get together, you review the work, you address any concerns or raise any concerns. And then you could say, "Yes, we all agree this feels like important work." And essentially, we're buying into the work that's getting done, and I really like that process. And then, as an extension of that, I really like how we often then pick themes. So as we are agreeing to the work, we're often grouping together work that makes sense where it's either the most cross-functional or collaborative. We're already going to be in that space together. We're aware of what everybody is working on. And those are the aspects that I really do like about sprint and some of the other styles, that more continuous workflow of where we're always pulling from a backlog. It feels more of a grab bag in terms of I don't really know what I'm going to get next. I don't know how this work has been reviewed or vetted. I haven't really gotten to talk to anybody, perhaps. I'm making some broad statements here. But I haven't really gotten to talk to anybody from the product side to understand this change. And I also don't really know what the rest of the team is working on, so I feel more disconnected from them. CHRIS: Yeah, I definitely share that, the planning or the meeting where we discuss the work that's coming up and shape it a little bit; I love that. Although it's interesting within the context of Scrum, I think like truly to the letter Scrum; my understanding is there are very discrete meetings, and they each have a distinct purpose. And so there's the sprint planning meeting, there's a backlog grooming, there's a sprint review and the sprint retrospective. And each of those are these four distinct meetings that are happening once every two weeks or so or whatever your sprint cadence happens to be. And the splitting of those becomes interesting. And some of the practices in there, I think, are...I think you and I share not being interested in doing them or not finding them to be super valuable. But I think broadly having some version of hey, let's sit down and talk about the work before we have to do the work, definitely a fan of that. For me, it often can be let's collapse four of those meetings into one sort of thing and maybe have it more regularly or something to that effect. But actually, we'll touch on the rest of those. But if you're good with bouncing from sprint/iteration, I think we've covered that topic well. Let's move on to one that I think we can do pretty quickly because I'm pretty sure I know how we feel, but sprint planning/planning poker/estimation. How do you feel about this one, Steph? STEPH: We grouped a couple of things in there. There's sprint planning, and then there's sprint poker, and those are different to me. CHRIS: Yeah. So let's go specific to the planning poker as the most pointed version of it but also generally estimation and sizing of stories. STEPH: Nope. Throw it out. I don't know how to play poker. Let's just get rid of it. [laughs] I was never a good poker player. CHRIS: Playing poker can be fun, but planning poker...Well, so actually, to ask a slightly different question, I think in the past we've talked about keeping aspects of it, definitely not keeping the let's figure it out, let's hash it out. Let's get down to an exact point value, and then we know we can have 34 story points a week, and that's what we're going to do. But the version of using planning poker, using this numerical communication tool to see if we're aligned, that one I think we've talked about liking that. I have enjoyed that, but under the strict guidelines that we throw the numbers out. The numbers are only a communication tool. They get thrown out after the fact. We do not commit to a set amount of work or anything like that. We just use it to say, "I think it's an eight. I think it's a one. Oh, we should talk," just for that. That's when it's useful. STEPH: I agree. Yeah, in my previous answer I was being flippant about it, but I do agree very much where I don't like the specificity of where you're trying to plan exactly what numbers are these. But I do find it very helpful for the reasons that you just said where the team agrees with the estimation around how long they expect something to take. Because then that is really great where you have someone who's never touched the codebase, and they're like, "I think it's a five or whatever system we're using here." It's an elephant...whatever scale you're using. And then someone else is like, "Well, I think it's a doughnut size." I'm making up silly stuff because it's more fun for me. And then those two people can talk and reconcile. So I do like discussing the estimation of work for that purpose but then not actually writing it down or maybe going with t-shirt sizes, something that's more simple, and then doesn't have anything with points, really. Anything with points can then be gamified and also brings out people's more competitive side. So, if you can make it something that's more fun, maybe around t-shirt sizes or a bunch of cute animals, various sizes, whatever works for your team. I'm trying to think of other fun measurements now [laughs] that we could use instead of t-shirt sizes. CHRIS: There are the sizes of bottles of wine as you go past. So there's a regular bottle of wine, and then there's a magnum. And then it gets to weird names like a Nebuchadnezzar and other things. These are big performative champagne bottles. So I think we should use that kind of sizing because I think they also have a geometric progression type thing, not quite Fibonacci but something like that. So I'm going to make that push for Nebuchadnezzar as being my go-to [chuckles] sizing in story points. STEPH: I have never heard of that, and I love it. That's great. CHRIS: Okay. We'll find a relevant link to the wine bottle sizing, and we'll put that into the show notes. We will also, of course, include a link to your wonderful blog post. What's the story with story points that you wrote with Matt Sumner? Because I think that really does dial into this topic really well. And again, coming back to that core idea around Agile, while we see value in the item on the...which side is it? While we see potential value in story points, I have worked with countless teams who desperately wanted to make this thing work. So it would be great if we could quantify the work and then numerically understand the work that we had ahead of us and sequence things and talk about deadlines and whatnot. Man, that would be amazing. I would really love to do that. So with every other developer and every manager of a team of developers in the world, I have not seen it done. I am still looking for that day. When that day shows up, then I think this will be a wonderful practice. But unfortunately, my experience has been that this doesn't work, and trying to do it causes more harm than good. STEPH: I agree that I certainly understand the reason that people want story points to work because it's very nice to then say, "We can calculate, and we can measure, and then we can have delivery dates." And that's really nice from a management perspective. But that does blend in nicely to the next topic, which I think fits nicely underneath the Agile umbrella, our daily syncs. Because that does bring us closer to that goal of where we can't give real valid updates on how something is going and provide a more real estimate as to when we think something is going to get delivered. That doesn't have the same effect of where we think we're able to plan and then promise delivery dates a week in advance because we're getting those updates in real-time, but they're going to be more reliable. And that is, we're so much more than where we try to over commit to work or if we try to say how much time something is going to take. And that is so much more valuable to have that reliable update and estimate versus trying to trick ourselves into thinking that we know when something is going to get delivered. CHRIS: Yeah, I think the daily sync or sometimes called the daily Scrum, or standup, or otherwise morning meeting often in the morning, this is one that I see lots of folks really hate, and I'm personally a big fan of. This is one that I would definitely hold onto. But I think you have to be very, very purposeful with how you structure it. It really should be as short as possible. And there's one particular thing that I see very regularly in teams, which is almost a performative version of what I did yesterday. It's trying to demonstrate to the team that yes, I, in fact, did work yesterday. I was a valuable team member. Please don't let me go from the team. And I think that's the sort of thing that we should try and just get rid of. There are definitely times where what you did yesterday is relevant to the team, or you worked on something, and now you have a bunch of questions, and bringing that to the team is useful. But that version of everyone needs to prove that they did work yesterday or...it's the sort of thing like if anyone says that sort of thing, then everyone else is like if you don't say what you did yesterday, then it sounds like you did nothing because everyone else is saying what they did. So you have to, I think, get a team buy-in to do this, say, "We're not going to talk about sort of bullet-list what we did yesterday. That's not going to get us anywhere as a team." But what's useful are those little magical moments of connection where I say, "Yep, I'm working on this. I'm going to implement it in this way." And someone's like, "Wait, wait, that way? Oh, we shouldn't implement it that way." And then ideally, what happens there is okay; let's connect after this meeting. You've now made this connection, but you don't need to hold up the rest of the meeting for that. You can just say, "Cool, this connection has been made. That's an incredibly valuable little point in time, but now let's continue on with the flow of the meeting," so that it keeps that rapid pace. And so times where you're blocked, times where you have questions, times where you're just describing what you think you're going to be working on. So if anyone's like, "Oh wait, no, we needed to stop that work because we actually made a decision yesterday that impacts whether or not we actually wanted to build that feature at all." If you can head off incorrect work at the pass, there's so much potential value in that meeting that it is interruptive. And it does take up some time, but I find that it is so, so worth it if you're able to really keep it focused, keep it concise, and keep that end goal of those little connections. When those happen, they're so valuable. So I think it's really worth the input. STEPH: I'm still smiling from where you said performative of what I did yesterday because that is something that took me a while to understand, one of the things that I did not like about the daily sync or daily meeting whenever your team gets together to talk about the work that's being done. And it was finally when I realized we're just going through a list of who has the longest list of the things that they accomplished yesterday. And again, it felt like it was bringing out more of that competitive mode in folks to talk about what they did, and it didn't feel very useful. Every now and then, maybe there was one thing that was interesting that someone did. But most of the time, it was always more helpful to hear what the person was working on that day for all the reasons that you just highlighted. There is one practical concern that I have with these types of meetings or with these types of events. And it's where you'd mentioned where if we can keep it concise…and someone brings something up, and it starts to devolve into a conversation right there. So then whoever was up next is now waiting while that conversation is happening. And that part gets awkward because then there's usually one person who is then willing or no one frankly is willing to then say, "Hey, so sorry to interrupt, but let's actually table this discussion and let everybody else go, and then we'll come back to this." And if you have people on the team that have been there for a long time with that culture, then that will just work because everyone will keep each other in check. But otherwise, if you're starting that new process, or if you start to notice there's always that one person who's doing that awkward thing of trying to then set that culture of this is how we do our daily chat, and these are the things that then we wait for later, it's really hard. And I say that because I have often been that person that's in that space where then I encourage people to table a conversation. And it always just feels awkward to interrupt someone and ask them to please wait until everybody else has gone. CHRIS: I share your hesitations around that, but it is very important. And it's that sort of ideally someone in a more senior position will model that behavior and model it in a positive, friendly way. Where I have done that often it's in the form of a question, so it's, "Actually, do you think maybe we could take this offline?" or something like that. Not a command, not taking over or shutting people down because it is somewhat interjective, and you're sort of correcting course. And so, being as friendly and empathetic in that moment as possible, but that's a hard note to strike. And again, if it's something that only one person is like the taskmaster, the Hermione Granger of the team who's trying to keep everyone focused and doing their homework sort of thing, nobody wants to be that. Well, Hermione did, but otherwise, nobody wants to be. STEPH: I love all the Harry Potter-themed references that have been coming through in the last couple of episodes. And I agree it is something that's hard to help teams course-correct, but it's important, and it's very much something worth doing. I just recognized that I think that's why these roles get implemented, why there's this concept of a Scrum Master, and then why we designate these tasks to specific people because then you have someone who can do it. And then when they do interject, it feels more appropriate because that is their role, and that's one of the things that they're supposed to do versus putting it more on the social pressure of whoever is comfortable speaking up to then course-correct. So I do understand where that implementation of Agile has then tried to create those roles, which I've been on teams that have a Scrum Master. And my experience is it's often been a very positive experience because the person that is in that role is often very kind and caring about that team. And so they are a wonderful person to work with, but it's also one of those...I've also been on teams without them, and things have been fine. So I have mixed feelings about that one. It's one of those; it feels like an extra heavy process, but I've also been on teams, and it worked. CHRIS: It's interesting the way you frame it, of the utility of that role. Like, having a role where we've now all bought into the idea that this person may take these actions say, "Hey, can we take that conversation offline?" and rather than one individual choosing to do that. I like that framing. I share what you're saying about the rest of the baggage that comes along with having this formal position, and often, that person is otherwise removed from the work. That can often be an aspect of Scrum. I think that gets complicated. But now I'm wondering can we make a software solution to do this? Because, of course, that's where my head goes. Can we have a standup bot that is listening and is like, "Hmm, it seems like you two people have been talking for the past two minutes. I'm just going to interject like my little bot self that I am and ask maybe take this conversation offline," in the way that we've sort of automated a lot of code formatting things, and that's been really wonderful, so that's not a part of PR review. Can we do the same for standup? I don't know. STEPH: I think all the award ceremonies have these where they start to play the music, and that's your cue to move off stage. CHRIS: Oh, I like it. STEPH: I think that's it. [laughs] So you cue the music whenever someone has been going for quite some time. On a slightly separate note but still related to this, some conversations that have been bubbling up around me have been related specifically to this idea around stepping in to say, "Hey, I'll take on that thing that you need a volunteer for," or "Hey, I will help the team stay on track," will often fall on people with a specific personality and then they will often be the one that continues to do that. And so they will end up taking on additional work or taking on additional roles just because they may be in a more empathetic spot where they feel that's the kind, helpful thing to do. And so, we've been looking for more ways to make sure that those tasks are being distributed evenly across the team. So we're not just waiting on someone to say, "Who would volunteer for this?" And then typically being the same handful of people that are always speaking up and then volunteering for it. And then trying to shift to more of a purposeful approach of having a queue of people and then cycling through that queue, and then if someone can't do it at a certain time, then we move on and then we just put them back in the queue. But this way, we don't have people that are typically just always taking on these responsibilities. And that's something that is a new consideration for me but one that I have found really helpful to be aware of and notice on your team who's the one that's always volunteering for these roles and checking in with them to see if they're comfortable with this, or if they're feeling compelled to volunteer for stuff because they may feel more inclined to speak up versus others are okay with staying quiet. But circling back to some of the Agile discussions earlier, you'd mentioned a handful of meetings and that you have some feelings about those meetings. What are those meetings that you have feelings about? CHRIS: Yes, the meetings. So again, this is somewhat contextual to Scrum, but the structure of Scrum has a handful of meetings that sort of define the sprint. So you have some at the beginning, the middle, and the end. So there's sprint planning, there's backlog grooming, there's sprint review, which typically includes a demo for stakeholders, and then there's sprint retrospective. And these, as far as I understand it, are four distinct meetings and are intended to be kept distinct so that their purpose stays purified in each of those meetings. And I think my feelings would be that again; I don't really find a ton of value in the sprint structure or in the two-week cadence or things like that. And so I think it can make sense in those contexts to be like, we need to make sure we have space for these things. But in a more continuous context, I think the backlog grooming or, more generally, let's talk about the work that's coming up. Let's make sure that we're all unified in how we're thinking about that work, what we think matters, what's prioritized. I think that is an incredibly valuable meeting. I think sprint review and specifically demo for stakeholders I'm really intrigued by that one. I don't know that I feel like that needs to be a distinct meeting. And in fact, more and more these days, almost every feature I deliver has either screenshots or a screen recording of what that workflow looks like. So we're continuously demonstrating to the stakeholders what does this look like now that it's a real thing? What does an end-user see? What's that experience like? And in retrospect, I think we'll probably spend a minute on that one. I like retros; some people hate retros. Yeah, let's loop back to that. But of those, what are your thoughts? What do you like? What do you not like about those meetings? STEPH: I think grooming is a very helpful meeting that can help a product manager and a technical team have discussions about the upcoming work. I don't necessarily think it needs to be the whole team. I think it can be a couple of engineers from the team; maybe those people rotate, maybe it's the team lead. And they get together with the product manager, and they essentially answer any technical questions about upcoming work. So then it can be refined. So then, as we get closer to that planning session, whatever we want to call it, then it feels more in a ready state for folks to react to and then have opinions on. So I do like grooming, but I wouldn't necessarily advocate that the whole team needs to be present for those. For a demo, I'm with you; it really depends. I've worked on projects where the stakeholders are less close to GitHub and Slack and areas that we could demo some of the work that's being done, and maybe they weren't poking around on staging as much. So it was really helpful to then have a more formal demo to then show them the work that's being done. And then I've also worked on plenty of teams where a demo was something that we used as a fun internal event where we have all these different teams, and we get together. And then we get to show off all the great work that we have done across all the different products. So then us, as fellow teammates, can then celebrate what the other teams are working on. Retros, you know I love retros. I think retros are a microcosm of your team's culture and process. And if your team is struggling to have a productive retro, your team is struggling. Because I think that is representative of your team's ability to get together, and reflect, share concerns, celebrate wins, agree on what's important, and run measured experiments. And if you're not having a retro, then I think you're not going to know how your team's doing until it's too late, and it's going to be harder to course-correct. CHRIS: #HottakeswithSteph. I like it. I like the intensity that you came in with there, but I know retro is near and dear to your heart. So I'm unsurprised that that is the line that you've drawn. I definitely share all of those feelings, particularly around retro, because I think much like the daily sync, I've seen many people who are just like, "This is a bad meeting. It's useless. Nothing ever happens. I don't like it." And I'm often surprised by that because I've found so much value in it. Retro similarly is this magical meeting that can just regularly change the course of how we're working as a team. But I also have come into plenty of teams where it definitely did not have that shape, where it was basically a place that everyone sits down, and somewhat downtrodden restates their list of grievances, their airing of grievances, and then nothing changes. And much like the sprint iteration thing where you're constantly missing the commitments, and that's just going to wear a team down. I think if you constantly have retro and nothing changes and it's that same list of concerns, then that is going to be bad, but that, like you said, is not the reason not to do it. [chuckles] Oh, we just keep saying the same things in retro, so I don't think it's even that valuable. I would say that maybe we should change the things. But I've definitely been on plenty of teams where retro was just so valuable. And it's definitely one where I feel like having a facilitator, having someone who is in that particular seat trying to guide the conversation without necessarily being in the conversation, can be incredibly valuable. There are also structures that I've seen work particularly well. We have a video on Upcase that we can link to. That's a format that I've found; it's a very lightweight format, but it basically involves getting everyone's input on a positive note, on a more critical note, and then revisiting and sort of sorting and waiting, and then digging into topics that need a little bit more focus. But I think a lot of different formats can work as long as retro is a way for people to sincerely meet up, safely talk about the things that they are feeling about the work, and then ideally, some change comes about as a result of that. You mentioned having measured experiments, and I love that as a framing or like something that retro can do for us. STEPH: I really do think that retros are so important because they're the health check of the team. As you'd mentioned, if people are having a very negative retro experience, which I understand, I've had very negative retro experiences as well, and I've walked away feeling like that was not a productive use of my time. But then that is our warning. That is our signal that's saying, "Something is not right, and something's not great, and we're not working together as we really want to be working together." And this retro is just that reminder that is right in our face, that is making this so uncomfortable and feel like a waste of our time because it is informing us that something needs to be improved upon. And we can feel like retros are not productive when we feel powerless to make that change. And that again is then another discussion to have with the team, to have with management, leadership, to talk about how do we get the power to then make the changes that we need to then have productive, happy retros? Because that's going to be a reflection that you have a happy, productive team. CHRIS: Love it, love the framing, love the symmetry there between team happiness and retro happiness. So to summarize, I think we've gone through most of Scrum now. So just to...correct me if I'm wrong on any of these, but I believe sprints and iterations, nah, we'll leave it. Planning poker, definitely not. That doesn't seem good, although maybe just to bring up conversations, but not as an artifact that we save in any way. And then otherwise, daily sync, we're fans. Retro, definitely fans. Sprint review, backlog grooming, some version of those, a lightweight version of a bunch of the meetings seems may be good, but a couple of things definitely are going to leave on the cutting-room floor. Does that sound about right to you for Scrum specifically? We've got other topics to cover. STEPH: Yep. All of that list sounds really good. CHRIS: All right. So we've now found our refined version of Scrum, re-Scrum as we'll call it. But now there's a couple of other pieces...So Scrum is very focused on the ceremonies and the team activities, but there's another facet of the Agile umbrella, which is Extreme Programming, which that's a book. I believe Extreme Programming Explained is the name of the book. And there are various different links that we'll include to point at those. But there are two particular practices that stand out that I have heard some people love, some people do not. So we'll go into both of them. The first is pair programming. What do you think, Steph? Do you like pair programming? STEPH: I do. I'm a huge fan. [laughs] Yes, I very much like pair programming, although it still has its limitations. I definitely want time on my own, and I can get exhausted from pair programming. It is a very vulnerable experience, too, where you have to share with someone: this is what I know, this is how I work, this is how I think. And I think that is incredibly challenging. I find that I am typically more productive when I'm pairing with someone or when I have the opportunity to pair with someone at least every couple of days. CHRIS: Yep. I'm definitely a huge fan of pairing. Although I think specifically to Extreme Programming, I think the idea is 100% pairing. I think you already spoke to this, but pairing is exhausting. And the idea of 100% pairing is I can't really even imagine that; even 50% pairing feels like an incredibly high bar to hold for any extended period of time. There's a recent article that was going around the mortifying ordeal of pairing all day, which spoke of one person's experiences getting deeply burnt out just going through that process. And so, as valuable as pairing is, it's definitely a tool to be used not all the time. That feels like a lot. STEPH: That's a lot of Stephanie singing because I tend to sing a lot whenever I'm stuck or thinking through things. So that's a lot of singing that I don't know if the world wants. CHRIS: I mean, based on all of the various Bike Shed intros that involve you singing, I think the world wants it. That's maybe one person's take. But definitely, something that you said of there's a vulnerability to it. And so many pairing sessions I've either been the one saying this or someone else that I was pairing with has said this to me, but they're like, "I swear I know how to type, just now that someone's looking, my hands don't work." It's like you're in a dream, and your legs don't work. You're like, I know how to run, I swear. But for some reason, my legs are made of jelly right now. Or you can't remember a particular method, or there's just something that happens, and so getting over that hump, getting comfortable with it, I think it is a skill and something to become accustomed to. And so, again, being conscious of that when you start doing it is super important. STEPH: I don't know if this is true because I only have access to people's thoughts when I'm pairing with them, and then they're sharing their thoughts with me. But I do feel like people tend to beat themselves up more when they have someone watching because then you feel the need to say, "Oh, I normally can type, but because someone's watching..." which is so true; that definitely happens. But those moments are some of those really great moments to then reflect on the fact that just because someone's watching us doesn't mean that then we suddenly need to beat ourselves up. And I don't know how philosophical that I want to get with this, but I feel like there are so many opportunities while pair programming to then encourage other people around us to be kind to themselves. That is one of the things that I have really benefited from pair programming is learning to be more kind to myself. And even if I don't know exactly what's happening or what I'm doing and I may not be as confident with someone else, I can still be positive and kind. Just because you're in a vulnerable space doesn't mean that you then need to be unkind to yourself. CHRIS: Yeah. I definitely agree with the idea of being kind to yourself also, where you can, be kind to someone else who you're pairing with, especially if they're finding that they're like, "Ah, suddenly my hands don't quite work." But I have pretty uniformly seen that a pairing session may start out that way. And then as everybody kind of just relaxes into it, suddenly you'll see someone just kind of flying around their editor. And you're like, wait, what just happened there? That was so fast. I don't even know. And so there's just this comfort level that sometimes it takes a little bit of time to ease into. But yeah, so pair programming, broadly yes. 100%, oh, that's going to be a no, no, thank you, not that. All right, so one other practice that comes from Extreme Programming, which is Test-Driven Development AKA TDD. What do you think about that one, Steph? STEPH: I feel like you're giving me lay-up questions here. For anyone that's familiar with us, [laughs] I feel like this is an easy one. Test-Driven Development is a thing. It's a thing that I enjoy. I don't always write tests first, though, so I don't always follow TDD, but I am definitely a fan of tests. So, I guess in that light, it's not so much that I adhere always to TDD. I don't feel the need that I have to write tests first, but I have found that with practice, that often helps me write code where I have tests then help me write out the logic for my code. So generally, yes, thumbs up on TDD, but I'm also not terribly strict about it where if you want to write some code first, write some code first. CHRIS: Yeah, I think I'm definitely in the mode where I like testing. I like Test-Driven Development. I can't always pull it off, frankly. It's hard. It is hard to know how to write a test in advance of the implementation that you're going to write such that the test will correctly constrain the system that you're about to write. That takes a couple of levels of knowledge that if I'm writing a Rail's controller action form sequence, I can probably TDD that because I've done it so many times. But if I'm doing something that's a little bit more new, novel, less familiar to me, then likely I won't be able to pull it off. TDD is like a fancy move that I don't always have available to me. But I consider that whenever I'm in that mode like that's not oh, it's fine to just write the thing before the test. Like, I want to be able to do TDD 100% of the time. I'm just not a good enough developer, frankly. And I don't know that I ever will be because I always want to be working a little bit past the edge of my comfort. So it's a delicate line of when I will not use TDD, but wherever I can, wherever I do have that level of knowledge of the system and the frameworks and whatnot built up, I find it is a vastly more effective way to work. It's not that I feel cool when I do it. It's like I feel much more effective. It helps me stay focused and on task and get the thing done. So it's very utilitarian in that way but also not something I can always pull off. STEPH: So, circling back to when we first started chatting, you were asking about Agile and then my thoughts about it. And having this conversation with you, I'm realizing, or I think I was already aware, but it's helping me re-solidify I'm very much a fan of Agile. There are specific implementations of Agile that I don't find enjoyable, and I don't find helpful to writing software, and I don't find helpful from the project management side either. But broadly speaking, I'm still very much a fan of the approach that we use generally for Agile, where we want to work in small deliverable increments, and then we also want to have the ability to change any moment what is the most important thing to work on? To me, that is the heart of following the Agile process. And I don't think that's going anywhere. Like, I don't think Agile's going to disappear. But I wouldn't be surprised if we see another implementation of an Agile variety of the things that you and I just shared and the things that we like. And so, I feel like most teams that I work with follow Agile within their own unique bespoke version. And we don't have to give it names because everybody's going to have their own custom version where they decide which process works for them and which one doesn't work for them. And that's what retros are for so then you can figure out which process works for you. CHRIS: Once more, Steph on the record about her love of retro. I think the core of Agile, the Manifesto, those core ideas about small iterations, delivering value, staying close to stakeholders, all of that feels deeply true to me. And I would be really surprised if a year from now or two years from now I was doing something that was wildly different from that. But then each of the layers of practices on top of that to varying degrees I like or don't like. And I wouldn't be surprised if aspects of that were swapped out down the road. But that core, that idea of this is how we think about building software. I like that thing; that seems like a good thing. So I'm going to hold on to Agile for a little bit longer personally. STEPH: Same. I still see Agile in my future. On that note, shall we wrap up? CHRIS: Let's wrap up. STEPH: Show notes for this episode can be found at bikeshed.fm. CHRIS: This show is produced and edited by Mandy Moore. STEPH: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or a review in iTunes as it helps other people find the show. CHRIS: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed on Twitter. And I'm @christoomey. STEPH: And I'm @SViccari. CHRIS: Or you can email us at hosts@bikeshed.fm. STEPH: Thanks so much for listening to The Bike Shed, and we'll see you next week. All: Byeeeeeeee. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

In this episode of the iPhreaks Show, the panel discusses iOS and other development books that are great resources to help during the course of the iOS developers’ journey. Sponsor CacheFly Panel Alex Bush Charles Wood Links iOS Programming: The Big Nerd Ranch Guide Cocoa Design Patterns Pragmatic Programmer Soft Skills Complete Software Developer’s Career Guide MaxCoder’s Guid to Finding Your Dream Developer Job Refactoring Working Effectively with Legacy Code Clean Code Design Patterns Clean Architecture Structure and Interpretation of Computer Programs Growing Object Oriented Programming, Guided by Tests Reactive Programming with RxJS Practical Object-Oriented Design Using Ruby Test Driven Development by Example SmallTalk Best Practice Patterns Extreme Programming Explained Picks Alex Bush: Robert Heinlein, Author Charles Wood: Breath of the Wild The Church of Jesus Christ of Latter-day Saints Follow iPhreaks Show on Twitter > @iphreaks

In this episode of the iPhreaks Show, the panel discusses iOS and other development books that are great resources to help during the course of the iOS developers’ journey. Sponsor CacheFly Panel Alex Bush Charles Wood Links iOS Programming: The Big Nerd Ranch Guide Cocoa Design Patterns Pragmatic Programmer Soft Skills Complete Software Developer’s Career Guide MaxCoder’s Guid to Finding Your Dream Developer Job Refactoring Working Effectively with Legacy Code Clean Code Design Patterns Clean Architecture Structure and Interpretation of Computer Programs Growing Object Oriented Programming, Guided by Tests Reactive Programming with RxJS Practical Object-Oriented Design Using Ruby Test Driven Development by Example SmallTalk Best Practice Patterns Extreme Programming Explained Picks Alex Bush: Robert Heinlein, Author Charles Wood: Breath of the Wild The Church of Jesus Christ of Latter-day Saints Follow iPhreaks Show on Twitter > @iphreaks

פודקאסט מספר 389 של רברס עם פלטפורמה - אורי ורן מארחים באמצע מאי, עם סימנים חלקיים של חזרה לשיגרת קורונה (דמיינו סאונד של שיעול קל) ואחרי המון זמן חזרה באולפן בכרכור את רועי אושרוב, פרק שנקבע לפני המון זמן בעולם אחר של לפני הקורונה (עוד דחיית קורונה בקטנה) - והנושא קרוב לליבנו: דיברנו בעבר הרבה על Continuous Deployment וזה יהיה הנושא העיקרי להיום (וסביר שעוד כמה נושאים נוספים באיזור).קודם כל - רועי: חלק מהמאזינים כבר מכירים, עוקבים ב-Twitter, Twitch ו/או השתתפו ב-Meetup (יש את CD/XP Israel ואת R&D Leaders), ובכל זאת קצת רקע - אז רועי אושרוב - מתכנת, אב לשלושה בנים נמרצים (עוד מעט חוזרים ללימודים…)מתכנת מזה למעלה מ-20 שנה - התחלה (מקצועית) עם Visual Basic ומאז עוד כמה שפות (וכן - לפני 20 שנה זה כבר לא היה Cobol, פה זה המתקדמים . . .) - היו #C ו-Java ו-++C ו-Python ו-Ruby . . . בימים אלה נכנס חזק ל JavaScript.בארץ עזרתי להקים את קבוצת Agile-Israel- ה-User Group הראשון שהוקמה כבר לפני יותר מ-10 שנים (כשארכיטקטים ב-Microsoft צחקו על “המשוגע עם ה-Agile וה-TDD")כתבתי בזמנו ספר שנקרא The Art of Unit Testing, שבימים אלו אני מוציא את המהדורה השלישית שלו - אם הקודמים היו ב-#C אז החדש הוא כבר ב-JavaScriptגם כי כולם עובדים היום ב-JavaScript וזה קהל יעד מעניין - וגם כי רציתי קצת יותר ללמוד את עולם ה - Functional Programming וזה משהו ש-JavaScript (גם) מאפשרוזה גם מאוד מאתגר לנסות להעביר את העולם הזה לעולם החדש.המהדורה הראשונה וגם השנייה היו מבוססות #C - והשלישית היא בעצם Re-write כמעט שלם - אני כרגע בפרק הרביעי, ואנשים פשוט “קורעים” אותי עם ה-Reviews ואני לומד המון תוך כדי, זה ממש כיף.חשבתי שאני יודע JavaScript לפני כן, ועכשיו אני יודע כמה אני לא יודע - אומרים שאם אתה רוצה ללמוד משהו, תלמד אותו? אז בספרים הראשונים למדתי #C ובספר הזה אני לומד JavaScriptזה עולם יותר מסובך ויותר מאתגר - Multi-Paradigm: אם #C הוא Object-Oriented אז כאן גם Object וגם Model . . . מאוד מעניין.באיזשהו שלב נסעתי לחו”ל, Relocation לנורבגיה למשך 2-3 שניםהיה מאוד מעניין ומאתגר - עבדתי שם בתור יועץ.לאחר מכן נסענו ועבדתי בניו-ג’רזי, ומשם עברנו לקליפורניה - ולפני בערך שנתיים וחצי חזרנו לארץ (הילדים גדלו, והיינו צריכים לקבל החלטה של Fork או Merge בחזרה ל-Master . . .)עשיתם Unit Test  לפני כן? ה- Integration test היה לצאת ולראות האם אנחנו יכולים לחזור . . .אז חזרנו ומעכשיו עד סוף החיים יש את ה What-if? - חלק מהחוויות של ה-Relocation.המעבר לנורבגיה לא היה מטעם העבודה?לא . . . בזמנו היה לי בלוג וכתבתי את הספר והרצאתי בכנסים - וגם לימדתי בנורבגיה בערך פעם בחודש; זה הכניס הרבה מאוד כסף והיה מאוד כיף - ובאיזשהו שלב חשבתי על מה יקרה אם במקום שבוע בחודש אלמד ארבעה שבועות בחודש? . . .גם כסף וגם מקום נחמד . . .”אתה משוגע” . . . פרסמתי בבלוג שלי שאני מחפש עבודה בנורבגיה, יצרו איתי קשר מכמה חברות, מצאנו את החברה הנכונה לעבוד בה - ואז הגענו לנורבגיה והבנו שזו הייתה טעות כלכלית מטורפת . . .נורבגיה זה המקום השני הכי יקר בעולם - ואז הגיע החורף . . . היינו צריכים ללמוד איך לנהל שלושה ילדים בשלג, שבדר”כ יותר גבוה מהילדים: לקחת לבית ספר, להלביש, והכל בלי עזרת הורים ומשפחה מסביב - כיף גדול, ממליץ בחום (או בקור).זה היה אתגר שאני שמח שעשינו - למדנו המון על עצמנו בתור משפחה וגם על תרבות אחרת - אמנם גם שם עבדתי בהיי-טק, אבל כאן בארץ, כשאנחנו עובדים בתור מתכנתים אנחנו בתוך תרבות ישראלית, וכשאנחנו יוצאים מהארץ אנחנו בהרבה מקרים צריכים ללמוד חוקי התנהגות אחרים לגמרי - ולקח לי המון זמן ללמוד את החוקים האלה.התרבות הסקנדינבית ולאחר מכן התרבות האמריקאית, הפולטיקה של איך לשכנע אנשים, איך להגיד לא בלי להגיד לא, המון דברים מעניינים . . . אתגר מעניין ולמדתי המון, אפילו בלי קשר לטכנולוגיה.(אורי) לא רק להגיד לא בלי להגיד לא - זה איך לשמוע “לא” בלי שאומרים לך “לא” . . .(רועי) דווקא יש לי סיפור מצחיק על זה - כשגרתי בארה”ב, היה לי מנהל אמריקאי “עם הכפתור סגור עד החלק האחרון בחולצה”יום אחד הייתה לנו שיחה, ואחרי רבע שעה של שיחה, כשהרגשתי ממש טוב עם עצמי, הבנתי שהוא בעצם מנסה לתת לי פידבק שלילי, שעשיתי משהו לא בסדר.אחרי 20 דקות של שיחה, פתאום הייתי צריך לשאול אותו - רגע, אתה מנסה להגיד לי שעשיתי משהו לא בסדר?התשובה “באמריקאית” הייתה כמובן “אני לא חושב שהייתי אומר את זה ככה, אבל יכול להיות שיש אנשים שהיו קצת נפגעים . . . אבל עוד פעם, זה עניין של תרבות, לא בטוח, אני חושב שעשית את הדבר הנכון, אבל . . .”.בקיצור - הוא התכוון ל-”כן”, ולקח לי המון זמן ללמוד איך אנשים באמת מנסים לדבר בדרגות האלה, וזה קצת כמו ללמוד שפת תכנות, ללמוד את הניואנסים האלה.בהקשר הזה - הנורבגים הם יותר “קשים לקריאה” מהאמריקאים, או יותר קלים?הנורבגים יותר קלים, הם הרבה יותר Straight to the point - למרות שבהתחלה הם מאוד נחמדים ומחוייכים הם בסופו של דבר יותר סגורים, אבל הם יגידו לך אם הם חושבים שאתה טועה.הם עדיין יהיו מאוד עדינים - יחסית לישראלים זה הבדל מאוד גדול, ועדיין קשה (לנו) להבין אותם.אז הזכרנו על קצה המזלג את הנושא של Continuous Delivery -  יש שיגידו Continuous Deployment ואנחנו מנסים לפעמים להבין את ההבדל בין שניהם אז אולי ננסה לדבר גם על זה - למעשה, הנושא היה במרכז הפוקוס של לא מעט סטארטאפים לפני משהו כמו עשר שנים . . . בהמשך לשיחה מקדימה שעשינו, אני חושב שמה שמעניין באפיזודה הנוכחית זה שהיום זה כבר מעניין את כולם - לא מעניין רק את הסטארטאפים אלא גם את הארגונים הגדולים ביותראם יצא לך להאזין לאחת השיחות האחרונות שלנו עם נתי שלום פה בפודקאסט, הוא כינה את זה שם כמעיין "שרשרת אספקה” או “מערך ייצור” של חברות, כש-Contentious Delivery זה חלק בלתי נפרד מהדברים האלה, וחברות שלא ילמדו לעבוד עם ה-Flow המודרני הזה למעשה יכחדו - והוא לא מדבר על סטארטאפים, אלא על חברות מהגדולות ביותר בעולם, שהבינו את הנושא.אני (רן) מעריך שזה משהו שמעסיק אותך ביום יום . . .כן . . . אני אקדים ואגיד שכשחזרתי לארץ . . . אחד הדברים שעסקתי בו כשגרתי בארה”ב היה ייעוץ לארגונים מאוד גדולים בעולמות של Contentious Delivery ו - DevOps ו - Extreme Programming - ולמדתי לקחים, גם של מה אפשר או אי אפשר לעשות, איך לקדם שינויים ארגוניים מאוד מסובכים ברמה הבירוקרטית ועם המון בעיות - לא במקומות עם 50 אנשים אלא עם 50,000 עובדים.כשחזרתי לארץ, היו בערך 50,000 מיטאפים ישראליים - כשיש אחד על Python ואחד על Lambda ואחד על Semicolon, ואחד על Angular ואחד על פסיקים ועל נקודות . . .  אבל אין מיטאפ שמדבר או קהילה שמדברת על מה שמחבר בין הדברים האלה.יש מיטאפים על Agile, אבל מה שהצחיק אותי (עצוב, אבל בכל זאת) היה שכשדיברתי עם חלק מהאנשים בקהילת ה-Agile בישראל (שהשתנתה מאוד, חלק לטובה וחלק פחות) - חלק מהם אמרו, כשדיברתי איתם על Contentious Delivery, ש”זה לא אנחנו, אנחנו Agile”, מתוך איזושהי הנחת יסוד שכשמדברים על Agile Coaching או על Agile Consulting מדברים על התהליך ה Scrum-י או על SAFe וכל הדברים האלה - ו - Contentious Delivery זה חלק מהעולם של ה- Ops וה - Infrastructure וה - Pipelines . . .זו הבנה, לדעתי, שגויה לחלוטין של אחד מהדברים הבסיסיים ביותר של איך אנחנו אמורים לעבוד - השמן בגלגלים, מה שגורם לנו להיות אג’יליים, אלו אותם Engineering Practices, אותם מנהגים שבאים מלמטה, ובלעדיהם כל התהליך הזה מלמעלה הוא בסך הכל “עלים של ורדים שאתה מפזר על מיטה של קוצים” (מטאפורה נוראית, אני יודע, Work with me here . . .).אני (אורי) יכול מאוד להזדהות עם מה שאתה אומר, בכמה אספקטים - באיזשהו מקום Agile או Agile Practices - יכול להיות גם שיחד עם כמות חברות הייעוץ שיש סביב זה, נוצר המון Buzz מסביב ואלו בסוף Practices - אפשר ללמוד אותם, לתרגל אותם וכו’.כשמדברים על DevOps ו - Contentious Delivery ודברים כאלה - אז זה כבר משהו שצריך ליצור סביבו תרבות, זה לא רק “נעשה את הישיבה הזו ואת הישיבה הזו, נתעד ככה או נתעד אחרת”.(רועי) זה עוד יותר קשה - אתה ממש צריך לשנות התנהגות של אנשים(אורי) התנהגות של אנשים, תרבות ותפיסת עולם של מה חשוב, למי יש אחריות על מה והוא צריך לקחת את האחריות הזו - ויש פה הרבה עניין של Trust בהורדה של האחריות אל המפתח, ולא כל הנהלה יכולה לעשות את זה.(רועי) ואם ה-Trust הזה נלקח לפני שנים רבות על ידי איזשהו ארגון שהחליט לעבוד בצורה מסויימת, עשה מעיין “הפרדת רשויות” - והיום אנחנו נמצאים במצב שבו ארגונים מנסים לקחת חזרה את השליטה אבל אבל אנשים לא רוצים לתת את השליטה חזרה לפיתוח, כיוון ש”ככה לא עושים דברים” . . . למה “ככה לא עושים דברים”? “כי תמיד עשינו דברים בצורה אחרת”“למה עשינו דברים בצורה אחרת”? אף אחד כבר לא זוכר . . .(אורי) כן . . רן, אני לא יודע אם אתה מרגיש כמוני, אנחנו עשינו את הדברים האלה ב-2011 ב-Outbrain ביחד, עם הרבה דחיפה שלך (רן) למקום הזה, ומשם Outbrain ככה - ונראה לנו שככה העולם . . . אין כבר אנשים שלא עושים Contentious Delivery . . .(רועי) זה מה שאתם רואים . . .זה מה שאנחנו מרגישים - שזה כבר לא Novelty, ואם זה כל כך מושרש ומוטמע אצלנו אז כנראה שכבר כל העולם ככה, ואנחנו מופתעים לראות כמה זה לא ככה.(רועי) אני חושב שאתם חיים בסוג של בועה, אמנם מאוד טובה, שבה אתם נמצאים כמה שנים קדימה לעומת כל מיני ארגונים.הרבה ארגונים שאני עובד איתם, ובעצם כנראה יש כאן איזשהו עניין של הטייה כי בדרך כלל קוראים למישהו כמוני כשארגון לא מצליח בדברים האלה ולא כשהוא מצליח, אז אלו הארגונים שאני אראה . . .קוראים לי כשרוצים לכתוב Unit Tests טובים ויש Unit Tests ממש גרועים, או כשרוצים לעשות שינוי בתהליך של Contentious Delivery והתהליך לוקח חודשים ויש המון Bottlenecks באמצע - אלה החברות שאני רואה.מה שאני רואה זה שזה קיים בהמון חברות - כמעט בלי קשר לתעשייה שבה אנחנו נמצאים - ה - Patterns או ה Anti-Patterns שאני רואה כמעט תמיד קשורים לאנשים, כמעט אף פעם לא טכנולוגיים, הטכנולוגיה זה בעצם החלק הכי פשוט - ללמוד Kubernetes זה לא הבעיה שלנו . . .(אורי) Contentious Delivery ו - Contentious Deployment היו הרבה לפני Kubernetes (רועי) בוא נתחיל ככה - Extreme Programming, שלדעתי זה נושא שפעם היה והיום עומד לקבל במה בחזרה ובגדול, זו בעצם מתודלוגיה שהתחילה לדעתי באיזור 1996, והאדם שהביא אותה לעולם, לפחות מהזוית שלי , זה Kent Beck - הוא כתב ספר שנקרא Extreme Programming Explained וספר שנקרא Test Driven Development: By Example - שני ספרים שקראתי בזמנו ולמדתי מהם המון - הוא התחיל את העולם הזה.מכאן, Extreme Programming (או XP) מדבר על כל הדבר הזה - אחד מהם היה Contentious Integration, אחר הוא Test Driven Development וגם Pair Programming ו Refactoring ו - Shared Code Ownership - הרבה דברים שאנחנו היום רואים אנשים שמנסים לממש - הם באים מהעולם הזה.כשאתה (אורי)

Craig and Tony are at YOW! Conference in Brisbane and have a rockstar moment and catchup with Kent Beck, the creator of Extreme Programming, the pioneer of xUnit and author of numerous books including “Extreme Programming Explained” and “Test Driven Development“: Extreme Programming (XP) was born at Chrysler by letting go of conventional wisdom and … Continue reading →

We conclude our conversation with Ryan Singer, Head of Strategy at Basecamp and author of Shape Up, by asking him how the team functions without requiring code reviews or QA checks. Then he goes on to describe in detail their "hill" metaphor for progress measurement and why this method provides a useful narrative that goes way beyond sprint duration or story points. SHOW LINKS: - Shape Up: https://basecamp.com/shapeup/?ref=df - Daring Fireball intro to Shape Up: https://daringfireball.net/linked/2019/08/04/shape-up - Extreme Programming Explained: https://www.amazon.co.uk/Extreme-Programming-Explained-Embrace-Change/dp/0321278658 - Feature Factory: https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory - Petition the King: https://ronjeffries.com/xprog/articles/petitiontheking/ - Art of Action: http://www.stephenbungay.com/Books.ink *** We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us: see link on troubleshootingagile.com Tweet us: twitter.com/TShootingAgile Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

We continue chatting with Ryan Singer, Head of Strategy at Basecamp and author of Shape Up. Ryan explains the "shaping" and "betting" processes in more detail, including who does the various roles and what is crucial to get right when you set up a design-and-build system like the one they advocate. SHOW LINKS: - Shape Up: https://basecamp.com/shapeup/?ref=df - Daring Fireball intro to Shape Up: https://daringfireball.net/linked/2019/08/04/shape-up - Extreme Programming Explained: https://www.amazon.co.uk/Extreme-Programming-Explained-Embrace-Change/dp/0321278658 - Feature Factory: https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory - Petition the King: https://ronjeffries.com/xprog/articles/petitiontheking/ - Art of Action: http://www.stephenbungay.com/Books.ink *** We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us: see link on troubleshootingagile.com Tweet us: twitter.com/TShootingAgile Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

We start our conversation with Ryan Singer, Head of Strategy at Basecamp, by asking him to help us understand how their Shape Up process works and how they developed it. He explains how the fear of not shipping drove their movement to frequent delivery of carefully designed (or "shaped") features, why their teams avoid single-page apps to ensure designers can make the maximum contribution, and why they have neither front-end devs nor back-end specialists. SHOW LINKS: - Shape Up: https://basecamp.com/shapeup/?ref=df - Daring Fireball intro to Shape Up: https://daringfireball.net/linked/2019/08/04/shape-up - Extreme Programming Explained: https://www.amazon.co.uk/Extreme-Programming-Explained-Embrace-Change/dp/0321278658 - Feature Factory: https://cutle.fish/blog/12-signs-youre-working-in-a-feature-factory - Petition the King: https://ronjeffries.com/xprog/articles/petitiontheking/ - Art of Action: http://www.stephenbungay.com/Books.ink *** We'd love to hear any thoughts, ideas, or feedback you have about the show. Email us: see link on troubleshootingagile.com Tweet us: twitter.com/TShootingAgile Also, if you'd like to leave us a review on iTunes (or just like and subscribe), you'll find us here: https://itunes.apple.com/gb/podcast/troubleshooting-agile/id1327456890?mt=2

Pragmatic Programmer at 20 with Dave Thomas and Andy Hunt Guests Dave Thomas (https://twitter.com/pragdave) and Andy Hunt (https://twitter.com/PragmaticAndy): Authors of The Pragmatic Programmer (https://pragprog.com/book/tpp20/the-pragmatic-programmer-20th-anniversary-edition) and publishers of The Pragmatic Bookshelf (https://pragprog.com/). Summary I’m very excited to have Dave Thomas and Andy Hunt on the show today. Dave and Andy are the authors of the Pragmatic Programmer, which has a 20th anniversary edition that is out now, and they are the publishers of the Pragmatic Bookshelf, where they have (full disclosure) published my books a time or two. We talk about what’s changed in the new version, what being a Pragmatic Programmer means, whether there’s still a role for tech books, and how to make automated testing pragmatic. Somehow I avoid telling the slightly embarrassing story about the bad impression I made the first time I met Dave. Enjoy. Notes 02:52 - Revisiting the Book 20 Years Later and What Has Changed/Hasn’t Changed 06:41 - What it Means to be a Pragmatic Programmer 08:39 - Software Development as a Team Sport 12:56 - Extreme Programming Explained and The Pragmatic Programmer; Similarities and Differences Extreme Programming Explained (https://amzn.to/31xukpR) Agile Manifesto (http://agilemanifesto.org) 22:09 - Finding The Pragmatic Programmer Voice/Tone 24:55 - Roles for Dead-Tree Technical Books 30:36 - How To Make Automatic Testing Pragmatic Special Guests: Andy Hunt and Dave Thomas.

Kent Beck (@kentbeck) joined Ryan Ripley (@ryanripley) to discuss product development, Extreme Programming, certifications, and his new book on software design. [featured-image single_newwindow=”false”]Kent Beck[/featured-image] In this episode you’ll discover: Using the 3X’s to guide your product developmentMusings from Kent on Extreme ProgrammingWhat is limbo? How does it scale collaboration? Links from the show: Kent’s Website – https://www.kentbeck.com/Extreme Programming Explained by Kent Beck – https://amzn.to/2WKooHLThe Product Development Triathlon – https://www.facebook.com/notes/kent-beck/the-product-development-triathlon/1215075478525314/Take a Scrum.org Class with PST Ryan Ripley – https://www.scrum.org/ryan-ripley How to Support the Show: Thank you for your support. Here are some of the ways to contribute that were discussed during this episode: Share the show with friends, family, colleagues, and co-workers. Sharing helps get the word out about Agile for HumansRate us on iTunes and leave an honest reviewJoin the mailing list – Check out the form on the right side of the pageTake the survey – totally anonymous and helps us get a better idea of who is listening and what they are interested inLeadership Gift ProgramMake a donation via Patreon [callout]This pocket guide is the one book to read for everyone who wants to learn about Scrum. The book covers all roles, rules and the main principles underpinning Scrum, and is based on the Scrum Guide Edition 2013. A broader context to this fundamental description of Scrum is given by describing the past and the future of Scrum. The author, Gunther Verheyen, has created a concise, yet complete and passionate reference about Scrum. The book demonstrates his core view that Scrum is about a journey, a journey of discovery and fun. He designed the book to be a helpful guide on that journey. Click here to purchase on Amazon.[/callout] [reminder]Which topic resonated with you? Please leave your thoughts in the comment section below.[/reminder] Want to hear another podcast about the life of an agile coach? — Listen to my conversation with Zach Bonaker, Diane Zajac-Woodie, and Amitai Schlair on episode 39. We discuss growing an agile practice and how coaches help create the environments where agile ideas can flourish. The post AFH 107: Explore, Expand, Extract with Kent Beck appeared first on Ryan Ripley.

  EPISODE DESCRIPTION: In this episode, Phil talks to software developer Kent Beck, director of Three Rivers Institute (TRI) and author of multiple programming books. Kent shares his thoughts on how he looks at software development, the value of community and the untapped potential of engineering talent that exists in different areas of the world. KEY TAKEAWAYS: ­­­ (1.39) - Phil opens by asking Kent to expand on the introduction and tell everyone a bit more about himself. Kent explains that for the last 7 years he has been working at Facebook. His main focus, while there, was on the engineering culture. During those 7 years, he did a lot of writing, coaching and educating. As well as studying the culture as a whole. (2.18) - Phil asks Kent to share a unique career tip. Kent says: “It's easy to treat software development as a production process where there's some functionality and the more quickly you can produce it, the better you are and I think that that's it's an understandable mistake but a fairly large mistake.” “I prefer to look at software development as a learning process that throws off running software as a by-product. If you do that, you'll learn to do your job better and better, over time, and those improvements compound on each other.” (3.15) - Phil asked Kent to share his worst IT moment and what he learned from that experience. Kent said it was the first time he was fired. He went on to explain he was not paying enough attention to the feedback by saying: “I thought here's the job. I'm doing this job. That was much more important to me then what the team as a whole was trying to accomplish and I did my job as I saw it. It just wasn't what the person signing the checks cared about.” (4.09) - From then on, Kent has made a point of really listening and also making sure he is communicating effectively. He said: “So you’ll hear me, if I give a talk with question and answer, I almost always will say ‘Does that answer your question?’” (5.00) - Phil asks Kent about his career highlight or greatest success. Kent said – “Right at the beginning of my career, I stumbled into a relationship with Ward Cunningham, who would go on to invent the wiki. And it was really a mentor-student relationship, at first”. He explained how working with Ward gave him confidence in his abilities and reinforced, in his mind, the need to value his ideas. As well reinforcing the importance of listening to others. (6.43) - Phil asks if Kent felt it was the foundation of many of the things he went on to do subsequently. Kent said he thought it was. For example, “This habit of checking in started very much with the work that I did with Ward. So we would spend a few hours maybe programming something. And then we would go have a coffee and talk about not just the content that we'd worked on, but the process that we'd used for it.” Regularly checking in enabled them to pick up on little details at each stage. For example, something as simple as the fact that they had used 4 keystrokes for a process prompted them to ask can we make it 3? They optimized everything from the micro stuff all the way up to how does this fit into society. (7.39) - Phil asks what excites Kent the most about the future of the IT industry and careers in IT. Kent responds saying that 'things are going to definitely radically change'. He expands this statement by explaining that there's unbelievably good engineering talent in Africa which may lead to large-scale collaborations. Kent then states that "we're going to have to find ways of having finer-grain commits and quicker path to production, better feedback from production; but also we’re going to have to confront some of the limitations of the social structures that we’ve built around programming. (09.44) – Kent went on to say that things have the potential to change a lot but also the potential to stagnate if people become complacent. (9.55) – Phil asks Kent whether or not he thinks the trend of diversity will continue. Kent says, “I think the world has big problems, engineers and software engineers can be part of addressing those problems. We don't have near enough engineers to throw away five sixths of the world's engineering talent just because it happens to be female or have melanin in its skin.” (10.31) - What first attracted you to a career in IT? (10.41) – “My dad was an electrical engineer, and then a programmer. And when he gave me my first book about BASIC, it was like remembering. It was not like learning. It was just like, Oh, yeah, yeah, yeah, that’s how that works.” (11.00) – Phil asked - So you felt you found the logic behind it quite straightforward? It just worked with the way you think? Kent said yes and explained he took a microprocessor manual and just read it repeatedly until he remembered it. Even though he did not completely understand it. He knew that he just had to continue to work hard and expand his knowledge. (11.34) – What is the best career advice you ever received? Kent replied: “Um, I'm not much of an advice taker." (12.09) - If you were to begin your IT career again, right now, what would you do? Kent's reply was to: “Treat it as a learning process. Act as if you haven't graduated from school. This is just your next class and you're going to treat it as a learning process and when the class is over and you've learned the lessons, you're going to go to a different class.” The more diverse your learning, the more cross-fertilization happens. (12.55) - What career objectives are you currently focusing on yourself? (13.35) – “My focus is on longer-term relationships, especially with large scale software development. I think that's, that's something I have now a lot of experience with, and I have some ideas that aren't widely shared. So that's a focus. I'm also going to do individual coaching because I receive the benefits of that as a young engineer.” (14.13) – “It's much more highly leveraged to produce better engineers, than any amount of code that you could write.” He is also experimenting, so he can learn whether he has more leverage with an audience of geeks or business owners. (14.43) - What's the number one non technical skill that has helped you in your career so far? (14.57) – “I come to a place of compassion more quickly than a lot of people seem to. So if somebody is doing something that doesn't make any sense to me, I'll get annoyed just like anybody else. But pretty quickly I start to try to see the situation from their perspective. And I think that's a powerful habit.” “It is helpful for me to be able to see the situation from the other person’s perspective.” (15.54) - Can you share a parting piece of career advice with the IT Career Energizer audience. "Learning works better in a community" (16.29) – What’s the best way to connect with you? Kent says that his website is provides information about what he’s up to, what he’s written recently and where he’ll be speaking. (17.21) – Phil reminds the audience of the upcoming changes to the podcasts and the timescales for those changes.   BEST MOMENTS: (3.00) – “Even a small change in learning trajectory can result in a large change in productive capacity”. (3.57) – “I did my job as I saw it. It just wasn't what the person signing the check cared about.” (Don’t forget to really listen to the client and the team) (7.50) – “Things are definitely going to change radically. There's a huge pool of unbelievably good engineering talent in Africa that hasn't been tapped.” (8.35) – “The pull request, code review, merge, deploy model I think is starting to run out of steam.” (9.34) – “We're going to have to find ways of building and maintaining teams and teamwork across a greater variety of thinking styles and cultural backgrounds.” (16.01) – “Learning works better in a community. I learn faster, I learn better if I share that learning experience with somebody else.”   GUEST BIO: Kent Beck is the founder and director of Three Rivers Institute (TRI). His career has combined the practice of software development with reflection, innovation and communication. His contributions to software development include “Patterns For Software”, “The Rediscovery of Test-First Programming” and “Extreme Programming”. Kent has also authored multiple books, including “Test Driven Development By Example” and “Extreme Programming Explained”.   CONTACT THE GUEST - KENT BECK: Website: www.kentbeck.com Twitter: https://twitter.com/KentBeck @KentBeck LinkedIn: https://www.linkedin.com/in/kentbeck/ Books: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530 https://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658   CONTACT THE HOST - PHIL BURGESS: Website: www.itcareerenergizer.com Twitter: https://twitter.com/PhilTechCareer LinkedIn: https://www.linkedin.com/in/philburgess/ Email: phil.burgess@itcareerenergiser.com  

The Agile community recently lost its friend and one of its most inspirational members in David Hussman. Craig and Tony were privileged to speak to him in one of his last interviews at YOW! Conference in Brisbane. David Hussman’s YOW! 2017 talk “Learning in Product: How Wrong are You Ready to Be?” “Extreme Programming Explained” is … Continue reading →

In this episode, Adam talks to Ben Orenstein about the benefits of pair programming and how to do it effectively. Topics include: The benefits of pairing with someone more experienced than you The benefits of pairing with someone less experienced than you How pairing helps you build things faster Why pairing often removes the need for code review How to get started with pairing if you've never done it before Sponsors: Cloudinary, sign up and get 300,000 images/videos, 10GB of storage and 20GB of monthly bandwidth for free Netlify, incredibly powerful static site hosting for free Links: Tuple, the remote pairing tool Ben is building Tuple's Pair Programming Guide The Art of Product, Ben's podcast with Derrick Reimer Ben's blog Pair programming on Wikipedia "Extreme Programming Explained" by Kent Beck "How to Improve as a Programmer" Llewellyn’s strong-style pairing The Pomodoro Technique Vehikl podcast episode on pairing

In last week’s Build Tip, we dove into the importance of onboarding new hires, and the benefits your team and company will experience if you invest the time into doing it.   Next, you might be wondering, what do you do if you have more than one hire? Or you have a hire that isn’t familiar with the language or framework your team uses and you want to ramp them up quickly?   Have you heard of techniques like pair programming or mob programming, but aren’t sure if they efficient and effective?   Well in today’s Build Tip, we’ll be sharing why pair programming and mob programming can be beneficial to getting new hires up to speed quickly on a new language or framework, and help you scale your efforts efficiently and effectively.   Chris Jobst, who is a senior software engineer at Pivotal Labs is back to help us out!   As you listen to the episode you’ll learn the following:   Why pair programming may seem daunting but it’s very efficient How pair programming improves the quality of your code base and product What mob programming is Why it may seem inefficient to have everyone working on a single line of code at once with mob programming, but it’s actually very efficient when onboarding many new hires Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA. Check out these additional resources on programming methodologies: Extreme Programming Explained How can I practice pair programming? Mob Programming How Pair Programming And Mob Programming Help Quickly Onboard New Software Engineers Transcript   Poornima Vijayashanker:        Hey Ronan, how's it going with your new hires?   Ronan Dunlop:              Great. I did everything that you and Chris suggested and...but I've run into a small snag.   Poornima Vijayashanker:        Oh, what's your snag?   Ronan Dunlop:              Most of my new developers don't know RAILS.   Poornima Vijayashanker:        Oh, well just peer program with them.   Ronan Dunlop:              There's just one of me.   Poornima Vijayashanker:        Oh, that's right. And five of them. Well, have you considered Mob programming?   Ronan Dunlop:              That sounds dangerous. What's that?   Poornima Vijayashanker:        Don't worry, it's not. In fact, why don't we cover the benefits of pair and mob programming in today's *Build* tip?   Ronan Dunlop:              That sounds cool.   Poornima Vijayashanker:        Welcome to *Build*, brought to you by Pivotal Tracker. I'm your host, Poornima Vijayashanker. In the last *Build* episode, I shared some tips for onboarding new hires.                     In today's episode, we're gonna dive in and give you some more tips around how you can onboard engineers, get them up to speed on a code base or a programming language they may not be familiar with really quickly. And to help us out, Chris Jobst is back. You'll recall Chris is a senior software engineer at Pivotal Labs. Thanks for joining us again, Chris.   Chris Jobst:        It's great to be back, Poornima. Thanks again for having me.   What Is Pair Programming In Software Engineering   Poornima Vijayashanker:        Yeah, wonderful. So let's dive right in. What's Pair programming?   Chris Jobst:        Pairing is when you have two people sitting at one computer. We often have two monitors and two keyboards and two mics, and they're literally working on the same code at the same time.   Poornima Vijayashanker:        That's gotta be really time consuming to have two people doing the exact same task at the same time. What's the benefit?   When To Use Pair Programming   Chris Jobst:        It sounds really daunting, but it's actually very efficient. You're basically doing code review a hundred percent of the time.   Poornima Vijayashanker:        OK.   Chris Jobst:        And you get to refactor together, so you avoid a lot of these common things that you'll see in other code bases.   Pair Programming and Refactoring   Poornima Vijayashanker:        OK, so maybe for some folks that don't know code reviews or refactoring, maybe we could share what those are as well?   Chris Jobst:        Sure. Oftentimes before something gets committed or accepted into the code base, you'll have somebody review it and make suggestions and then the original committer has to go back and change it, and then it goes back to the code review and gets accepted.   Poornima Vijayashanker:        OK.   Chris Jobst:        That's a feedback loop that we completely avoid with Pair programming.   Poornima Vijayashanker:        And with refactoring?   Chris Jobst:        Refactoring is simply where you take code and change the implementation without changing the functionality.   Poornima Vijayashanker:        OK.   Chris Jobst:        To improve the readability and maintainability of the code.   How Pair Programming Really Works   Poornima Vijayashanker:        So in pairing, since you've got two sets of eyes checking each other's work, it probably moves a lot faster as a result?   Chris Jobst:        I think so. There's code review going on, you're refactoring together, you're always talking about the best way to solve a problem and if you don't know what to do, instead of having to go ask someone or stop and email, you've got your pair right there.   Poornima Vijayashanker:        Yeah. Which is probably the benefit for new hires?   Chris Jobst:        Absolutely.   Poornima Vijayashanker:        For our audience out there who may be new to pair programming, how can they get started?   Chris Jobst:        Well, you know one computer and another monitor, and you need two keyboards and mics. Most people already have that on hand.   Poornima Vijayashanker:        Yeah, and are there any rules, I'm guessing?   Chris Jobst:        Absolutely. The biggest one is have empathy, and just be kind to your pair. You're both working together, it's pretty intimate, but it's a lot of fun too.   Poornima Vijayashanker:        Now are both people writing code at the exact same time?   Chris Jobst:        No. You decide who's going to drive at a certain time and type on the keyboard and the other person will navigate and maybe suggest, "Hey, what if we went over here and did this thing?"   Poornima Vijayashanker:        So it's like a pilot/co-pilot and maybe you trade off?   Chris Jobst:        Yeah, that's a great way of describing it.   Mob Programming Versus Pair Programming   Poornima Vijayashanker:        Awesome. There are some situations where you can't Pair program, like in Ronan's case where he's got five engineering hires and they don't know RAILS so how can you work with a bigger group?   Chris Jobst:        Well, you can do what's called Mobbing.   Poornima Vijayashanker:        OK.   What Is Mob Programming   Chris Jobst:        You get one computer and often a TV screen or projector and you have a bunch of people, five or more, look at the code. One person is typing and you're generally more teaching or gathering suggestions about how to best achieve a goal.   Poornima Vijayashanker:        Got it. I'm sure somebody who's looking on from the outside is gonna be like, "Why are five people sitting around one machine and writing a single line of code?" What are some of the benefits? Why we would wanna do this?   Benefits of Mob Programming   Chris Jobst:        As you pointed out, it's great for onboarding new people.   Poornima Vijayashanker:        OK.   Chris Jobst:        And what you'll have is people asking questions, oftentimes they'll ask a question somebody else didn't think of but it's a question that they need answered.   Poornima Vijayashanker:        Got it. And I'm sure it also helps with the bus factor, right? Everyone's gonna know something, or know the same thing.   Chris Jobst:        Definitely, you want everybody on the same page. You want them all knowing how the code works and if you've got a bunch of new people, it's actually more time-consuming to go and teach every person individually than to get them in a room and help them learn from each other and from the person who's the expert.   Poornima Vijayashanker:        Got it.   Resources On Pair Programming And Mob Programming                     This was a great primer on pairing and mobbing. For our audiences out there who maybe want to dive a little deeper, do you have recommendations on resources?   Chris Jobst:        Definitely. There are two great books that I love. *Extreme Programming* and *Extreme Programming Explained*, both by Kent Beck. I recommend the former for engineers. It really talks about these practices and the process in more detail. *Extreme Programming Explained* is a great resource for PMs. It talks about it on a higher level and how a whole project can benefit.   Poornima Vijayashanker:        Thanks for sharing these great resources and tips for us. I know our audience is gonna get a lot out of this.   Chris Jobst:        Thank you for having me. I'm a huge proponent of pair programming.   Poornima Vijayashanker:        So, for all of you out there, Chris and I wanna know, have you done pair or mob programming with your teams as you onboard new hires? If so, what are the benefits you've experienced? Let us know in the comments below.                     That's it for today's episode of *Build*. Be sure to subscribe to our YouTube channel to receive more episode like today's and special thanks to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now.   This episode of *Build* is brought to you by our sponsor, Pivotal Tracker.

(@KevinTrethewey) and Danie Roux (@danieroux) joined Ryan Ripley (@ryanripley) to discuss the Spine Model and how to use it effectively with agile and scrum teams.Kevin Trethewey  [featured-image single_newwindow=”false”]Danie Roux Presenting[/featured-image] In this episode you'll discover: What the Spine Model is. How to use the Spine Model with your agile teams Use the Spine Model to find common ground Applying system thinking to team dynamics Links from the show: The Spine Model website – http://spinemodel.info/wiki.html Kevin Trethewey’s Site – https://kevintrethewey.com/ Danie Roux’s Site – http://www.danieroux.com/ Agile 2015 Talk on the Spine Model – http://spinemodel.info/news/agile2015talk.html Team Tourism – https://kevintrethewey.com/projects/teamtourism/ How to support the show: Thank you for your support. Here are some of the ways to contribute to the show: Share the show with friends, family, colleagues, and co-workers. Sharing helps get the word out about Agile for Humans Rate us on iTunes and leave an honest review Join the mailing list – Check out the form on the right side of the page Take the survey – totally anonymous and helps us get a better idea of who is listening and what they are interested in Leadership Gift Program Make a donation via Patreon Book of the Week: [callout]Accountability. Transparency. Responsibility. These are not words that are often applied to software development. In this completely revised introduction to Extreme Programming (XP), Kent Beck describes how to improve your software development by integrating these highly desirable concepts into your daily development process. The first edition of Extreme Programming Explained is a classic. It won awards for its then-radical ideas for improving small-team development, such as having developers write automated tests for their own code and having the whole team plan weekly. Much has changed in five years. This completely rewritten second edition expands the scope of XP to teams of any size by suggesting a program of continuous improvement. Click here to purchase on Amazon.[/callout] [reminder]Which topic resonated with you? Please leave your thoughts in the comment section below.[/reminder] Related Episode: Want to hear another podcast about the life of an agile coach? — Listen to my conversation with Zach Bonaker, Diane Zajac-Woodie, and Amitai Schlair on episode 39. We discuss growing an agile practice and how coaches help create the environments where agile ideas can flourish. Help promote the show on iTunes: One tiny favor.  — Please take 30 seconds now and leave a review on iTunes. This helps others learn about the show and grows our audience. It will help the show tremendously, including my ability to bring on more great guests for all of us to learn from. Thanks! Agile Dev West conference offers you the perfect opportunity to get away from distractions to immerse yourself and improve your agile skills in hot areas such as agile and lean development, scaled agile development, agile teams and leadership, digital transformation, and more. Agile for Humans listeners use code “AFH18” to receive 10% off their conference registration. Check out the entire program at adcwest.techwell.com. You'll notice that I'm speaking there again this year. Attendees will have a chance to participate in my half-day sessions on advanced scrum topics called Coaching Workshop: Taking Your Scrum to the Next Level, as well as Rethinking Your Retrospectives. I hope to see many Agile for Humans listeners in Las Vegas – June 3-8, for this great event. The post AFH 090: Walking the Spine Model appeared first on Ryan Ripley.See omnystudio.com/listener for privacy information.

Craig is at Agile 2016 in Atlanta and catches up with Mark Kilby, an Agile Coach at Sonatype and co-founder of Agile Orlando and Agile Florida. Along the way they discuss: “Extreme Programming Explained” by Kent Beck (the white book) Memories of Jean Tabaka and her book “Collaboration Explained” We should be collaborating with leaders … Continue reading →

#### In this Episode Chadrick Mahaffey is a software developer and fan of the SAFE Network. For years he's been working to understand organization principles so as to evolve a way that people can "Labor in Freedom." In this interview, we go into the background of how he arrived at what he now calls The Crowd Found Hub, a system using smart contracts and crypto tokens to allow for a very open and fruitful way to organize group activities in a completely voluntary way, but with a way of rewarding value created by participants. Could change a lot of the way we think about how we "have to" do things. #### Magic Word Listen for the magic word, and submit it to your LetsTalkBitcoin.com account to claim a share of this week's listener award distribution of LTBcoin. Listeners now have a full week from the release date to submit a magic word. The magic word for this episode must be submitted by 12 pm Pacific Time on May 17, 2016. #### Music Music for this episode: *SafeProject,* an original piece composed and performed by Nicholas Koteskey of Two Faced Heroes #### Links [Crowd Found Hub (In Detail)](https://forum.safenetwork.io/t/crowd-found-hub-in-detail/9064) [*Extreme Programming Explained*](http://www.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0201616416/ref=sr_1_2?ie=UTF8&qid=1462849265&sr=8-2&keywords=extreme+programming+explained) by Kent Beck [*Maverick*](http://www.amazon.com/Maverick-Success-Behind-Unusual-Workplace/dp/0446670553/ref=sr_1_1?ie=UTF8&qid=1462849425&sr=8-1&keywords=ricardo+semler) (1995) and [*The Seven Day Weekend*](https://www.amazon.com/Seven-Day-Weekend-Changing-Work-Works-ebook/dp/B000PDYVXE?ie=UTF8&keywords=ricardo%20semler&qid=1462849425&ref_=sr_1_2&sr=8-2) (2004) by Ricardo Semler [Technology and Choice website](http://technologyandchoice.com) [SAFE Crossroads podcast](http://safecrossroads.net)

We get to work to make sense of a sensemaking framework for human work systems, and learn how to build stronger teams with better communication. Kenneth & Kevin are joined by Danie Roux (@danieroux) & Kevin Trethewey (@KevinTrethewey) to chat about their Spine model, a sensemaking framework for human systems. Danie & Kevin are both involved in doing consulting work, and have distilled the Spine model from their experience helping teams in various companies. Having its roots in Extreme Programming and NLP, the Spine model is about having the right conversations. For more information on the Spine model: * http://www.spinemodel.info * http://www.spine.wiki Follow Danie & Kevin on the internet: * https://twitter.com/danieroux * http://www.danieroux.com * https://twitter.com/KevinTrethewey * http://drivenalliance.com Here are some resources mentioned during the show: * Extreme Programming - http://www.extremeprogramming.org * Nonviolent Communication - https://en.wikipedia.org/wiki/Nonviolent_Communication * Rhetoric - https://en.wikipedia.org/wiki/Rhetoric * Systems Thinking - https://en.wikipedia.org/wiki/Systems_thinking * Values elicitation exercises * Dreyfus model of skill acquisition - https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition * Pragmatic Thinking and Learning - https://pragprog.com/book/ahptl/pragmatic-thinking-and-learning * Heuristics - https://en.wikipedia.org/wiki/Heuristic * Cumulative Flow Diagrams - http://brodzinski.com/2013/07/cumulative-flow-diagram.html * Story points - https://agilefaq.wordpress.com/2007/11/13/what-is-a-story-point/ * Agile2015 Presentation in Washington DC - http://sched.co/370b * Complexity vs Complicated - https://hbr.org/2011/09/learning-to-live-with-complexity * Cynefin Framework - https://en.wikipedia.org/wiki/Cynefin_Framework * "Teams are immutable" - https://twitter.com/richardadalton/status/569275411508682752 * Extreme Programming Explained - http://amzn.com/0321278658 And finally our picks Kevin Trethewey: * Russell L. Ackoff - https://en.wikipedia.org/wiki/Russell_L._Ackoff * "Team Tourism" Danie: * Freedom from Command and Control: A Better Way to Make the Work Work - http://amzn.com/0954618300 * Lean Enterprise: How High Performance Organizations Innovate at Scale - http://shop.oreilly.com/product/0636920030355.do * The Nature of Software Development - https://pragprog.com/book/rjnsd/the-nature-of-software-development Kevin: * Coding Horror: The Book - http://blog.codinghorror.com/coding-horror-the-book/ Kenneth: * How to Build Stable Systems - http://bit.ly/217sVkr Stay in touch: * Socialize - https://twitter.com/zadevchat & http://facebook.com/ZADevChat/ * Suggestions and feedback - https://github.com/zadevchat/ping * Subscribe and rate in iTunes - https://itunes.apple.com/za/podcast/zadevchat-podcast/id1057372777

Extreme Programming (XP) é uma metodologia de desenvolvimento de software, nascida nos Estados Unidos ao final da década de 90. Esta metodologia foi criada por Kent Beck durante seu trabalho na Chrysler, onde se tornou líder de um importante projeto em março de 1996 e onde também começou a refinar o método que estava utilizando nos projetos.O método de Kent Beck em Outubro de 1999 se tornou o livro Extreme Programming Explained, o primeiro e mais famoso livro sobre XP.Extreme Programming vem fazendo sucesso e seus objetivos são alcançados através de um pequeno conjunto de valores, princípios e práticas, que serão tema do Papo de Casal de hoje.Baixe o episódio aqui!

After chasing him across the east coast of Australia, Craig sits down with Jeff Patton at YOW! Conference in Sydney. Along the way they fail to remember the subtitle of Jeff’s “User Story Mapping” book and talk about: Art school dropout to software developer to early Extreme Programming “Extreme Programming Explained” by Kent Beck (and we agree the … Continue reading →