Mario Lurig

Lots of company problems could be fixed by getting 50-100 ppl in a room with A+ facilitation and senior exec air-cover and support. Why this can't / doesn't happen is a big reason why change is so hard. Change is frequently a battle of change agendas. -- That can't happen out in the open. (Some) people are desperate for someone to blame. -- That is tough in a format where it is obvious there isn't one person to blame. (Some) people are too scared to let go of the reigns -- That happens when people work together to find a solution. We're too worried to put on the breaks and step away from keyboards -- Yep, that would happen. A senior leader is having trouble providing leadership -- That would become immediately obvious...people wouldn't want to meet and work together if there wasn't some signal it would be worth it There is a strong pressure to imagine teams and groups are independent. -- This is proven false when you get teams together. Finally, there is a deep-rooted fear of collective problem solving *working*. What would that mean? What would that mean for the managers who are tasked with working things out behind the scenes? What would that mean for efforts to solve problems in private? What would that mean for the person who thinks top-down actions are the only solution?

371

88 Comments

I feel like I’m in the twilight zone. In 2008 I said that you could do Scrum better if you considered it a partial implementation of Lean. Ken and Jeff rebuffed me. Then, the 2020 Scrum Guide said Scrum is based on empiricism and Lean (which it actually isn’t). I based this assertion on my work that year where I used Lean to help a company that had been trained by Jeff but couldn’t get teams to work together well. I used Lean and value stream analysis to create BLAST, which is discussed in my book with Cecil Rupp Steve Pereira and Richard Knaster The Lean Agile Way. BLAST, while a predecessor to Scrum@Scale is more flexible since you can use Scrum or Kanban. About 10 years ago the client I had created it for was used as a case study for Scrum@Scale so they apparently had learned something from it. Scrum folks do seem to be catching up, however. Over the last 5 years, I have any number of posts by CSTs talking about the need to manage work in process and use flow as well. I've recently seen CSTs arguing over whether Scrum uses timeboxing or not. If CSTs can’t agree on what the guide says how can we mere mortals. What makes it feel like I’m in the twilight zone is this morning a CST said they teach Scrum where you should “Take the parts that will be helpful. Leave them behind if not. Who cares if you can’t call it Scrum.” It just feels so odd that things I’ve been vilified for years for saying are now being presented by CSTs and Scrum thought leaders. Of course, there’s never been any acknowledgement of my saying these things. If there were, I guess I’d really be in the Twilight Zone. :)

20

20 Comments

Product discovery doesn't have to be so complicated. Most teams live at the edges...they either ignore discovery, or make it so complex that they feel overwhelmed. Take an 80/20 approach and make it sustainable with fewer tools, methods, and time. Get automated feedback, talk to customers, and create insights from the patterns that emerge. Remember, the goal is to understand customer needs and de-risk product decisions. DM me if your teams could use some help.

2

If you want your PS team to be more than just executors, invest in their ability to think like business owners—not just technical experts. Here’s why: The most successful PS teams are more than project executors. They’re strategic partners who can translate client needs into business value—AND understand how that value ties back to your company’s bottom line. But too many leaders are missing this crucial investment. They hire great technical talent, yet fail to equip them with the financial and commercial skills needed to truly scale. Here’s what happens when you level up your team’s business acumen: 𝗕𝗲𝘁𝘁𝗲𝗿 𝗱𝗲𝗰𝗶𝘀𝗶𝗼𝗻-𝗺𝗮𝗸𝗶𝗻𝗴. When your team understands the financial impact of scope creep, poor utilization, or inefficient processes, they make smarter decisions. 𝗦𝘁𝗿𝗼𝗻𝗴𝗲𝗿 𝗰𝗹𝗶𝗲𝗻𝘁 𝗿𝗲𝗹𝗮𝘁𝗶𝗼𝗻𝘀𝗵𝗶𝗽𝘀. A team that “gets” business speaks the client’s language, helping them articulate the ROI of your services. 𝗥𝗲𝘃𝗲𝗻𝘂𝗲 𝗴𝗿𝗼𝘄𝘁𝗵. Teams that think beyond deliverables create upsell opportunities, identify cost-saving initiatives, and expand engagements naturally. 𝗘𝗺𝗽𝗼𝘄𝗲𝗿𝗲𝗱 𝘁𝗲𝗮𝗺𝘀. When your team understands how their day-to-day work affects P&L, they start thinking like owners—not employees. How do you start building business acumen in your team? 👉 Teach them to read a P&L. A little financial literacy goes a long way in shaping better project leaders. 👉 Involve them in pricing and forecasting. Let them see the “why” behind decisions, not just the “what.” 👉 Pair junior team members with mentors who can help them understand the commercial side of projects. The result? A team that thinks strategically, executes flawlessly, and drives growth for both your clients and your company. What’s one way you’re helping your team improve their business acumen? Share your experience below!

9

4 Comments

I think that it's fundamental that newer generations join the conversation about Agile or our community will go extinct. This is my first attempt to help. Codename XYZ Agile or (AgileXYZ?) I believe our community is old. Sure Agile has been around "only 23 years" but the average age of the people talking about it is not at all low. Despite how I may feel internally, I am a middle aged man and it has been a while since I turned over 40. While I want to keep the conversation fresh I bring with me a burden of 20 years of experience that yes, gives me plenty of stories to learn from but also biases heavily any perspective I may have on how to do things differently. Yes because "I tried that and it didn't work". Many many times. We need young people. We need fresh eyes. We need brave people with the openness to fail. Fail in areas never seen before while attempting things already tried before. People who can lead really meaningful experiments and not just superficial tweaks to the already discovered. I don't know what I can do beyond reopening my pro bono sessions of mentoring & coaching. That what I would care about but would a Gen Z care about that? And how can I promote them so that Gen Z and those after them can hear my message? Equally if not more importantly: what things I am missing just because I can't think of them and would instead be super important for newer generations? ✍ If you are a young person, I want to hear from you what you need to enjoy your journey in the world of work. 🖐 If you think you are or want to be an ally for young people, I want to hear in what ways you are willing to help younger talents. PS: I would like to thank deeply 🔑 Sanjiv Augustine 🎯 & 🪓🎯 Chris Stone 🎯🪓 for inspiring this initiative. Sanjiv is the person who raised the need during the panel of day 3 of #agile2024 named Reimagining Agile. At the question "What do you wish for the future" Sanjiv answered "to see more young people actively involved". He then asked "hom many of you in this room are under 30?" 3 hands raised in a group of about 1000 people. Discomforting, even know that there were a few more hands that for various reasons didn't get raised. At the end of the panel Chris challenged us all to think about what we could do in actions beyond the nice words. As we had an entire day of Extreme Open Space facilitated by the great Allison Pollard & Jake Calabrese I decided to facilitate a 30 mins sessions to collect ideas. In the picture an improvised graphic recording of our conversation we had with a dozen of people who cared about the topic and contributed with their experience. I found it heart warming 🧡 #agilealliance

28

14 Comments

Scrum is not inherently difficult. I've gotten teams up on it in an hour. This is an overview of a section on my Amplio System Visual "Using Amplio to Improve Scrum." See https://bit.ly/3z5EMuY for a running entry of additions and take the top entry and click on the box labeled "Using Amplio to Improve Scrum" for more.   Scrum is easy to adopt when used in the context for which it was designed. It is only difficult to master when this is not the case or when the physics of flow is not understood. Scrum was inspired by “The New New Product Development Game." While Scrum can be for more than creating new products, it is immutable in its core practices. These include: * Teams are cross-functional * They are able to plan ahead 1-4 weeks. * A product owner is available on a regular basis   Another qualification is that teams should either know how to build the product or be able to learn it quickly. Scrum is more than this, of course, but the only constraints the additional practices provide are when they happen. This immutability makes Scrum not be fit for purpose for many teams. The following Scrum mantras hold teams back by both slowing down learning and requiring reinvention of known ideas. 1. “Scrum is based on empiricism.” Adding validated theory, sometimes called “the physics of flow,” enables people to relate their experiences to desirable Agile team practices. This improves understanding, quickens learning, and creates confidence. Without this, improvement will be slowed, if not stagnated. 2. “Follow until you understand.” Integrating validated theory with empiricism enables a small set of practices to be provided with understanding. Simple starts are possible with empiricism and validated theory. 3. “Purposefully incomplete.” This requires people to reinvent the wheel. The motivation for a simple start is good. Providing the information needed after the start, when it is needed, avoids a lot of rework. 4. “Cross-functional teams.” Having all the capabilities needed be on the team is good. But they are often not possible or even desirable. The combination of requiring them without allowing for alternative, better methods in certain contexts, creates waste. 5. “Sprints and planning ahead.” Many situations do not lend themselves to this. Interruptions may be the nature of the game. Planning ahead just wastes time in these situations. One-day timeboxing or a flow model is often better. I believe it's better to get a little understanding up front and then use that to learn instead of trying to follow a guide. You don’t need much to start if you can get the information you need later when you need it. Doing team-based Agile is very easy when you have the skills you need, an understanding of why small increments are good, and a cross-functional team. When you don't, you need more than empiricism and following someone else's ideas that supposedly work to solve urgent, complex problems that haven't been solved before. 

3

1 Comment

Another Amplio Mini-Lessons: The cost of interruptions. Are you often interrupted by managers or product owners? Maybe you need to be able to explain why interruptions are bad. Check it out at the Amplio Mini-lessons: The true cost of interruptions. Many managers and product owners don't appreciate the cost of an interruption. It's not merely delaying what's being worked on. It also causes wasted effort by slowing other things down. https://lnkd.in/gHqfqdiN

11

2 Comments

If you use spreadsheets for prioritization, you should read these quotes about how something like Pugh matrices are used (or are supposed to be used) in practice. "An iterative process of culling down and adding to the set of concepts under consideration" "The goals of this activity are: (1) a ‘controlled convergence’ on a strong concept that has promise of out-competing the current market leader; and (2) a shared understanding of the reasons for the choice." "In practice, Pugh matrices are messy collages of drawings and notes. This is a reflection of the nature of early-stage design. The PuCC process is simple and coarse-grained. Observation of teams show the method is also flexible and heuristic." "It is important to note that there is no voting in Pugh’s method. Let us consider a situation in which several experts claim that a concept is better than the datum and others disagree. In Pugh’s method, a discussion proceeds in which the experts on both sides communicate their reasons for holding their views. In many cases, this resolves the issue because either: (1) facts are brought to light that some individual experts did not previously know, (2) a clarification is made about what a design concept actually entails, or (3) a clarification is made about what the criterion actually means. " "A matrix run can result in at least four kinds of decisions (not mutually exclusive) including decisions to: (1) eliminate certain weak concepts from consideration, (2) invest in further development of some concepts, (3) invest in information gathering, and (4) develop additional concepts based on what has been revealed through the matrix and the discussions it catalyzed. To follow up on these actions, the matrix should be run iteratively as part of a convergence process." "As the case study by Khan and Smith (1989) shows, the PuCC process includes decision making, but it cannot be sufficiently modeled only as decision making. The process also involves learning and creative synthesis and there is no clear line when these activities stop and decision making begins. https://lnkd.in/gtwkHdQN

64

6 Comments

Product Managers should be using GPTs daily to improve their productivity and creativity at each stage of the product lifecycle. If you aren't, then don't miss this session with Andrew Overby!

29

6 Comments

Maybe the biggest challenge with Agile I saw yet again another Agile proponent talking about a problem in product development and how to fix it. This seems to me to be the big issue with Agile. We create problems and then talk about how to solve them instead of figuring out how not to create them in the first place. The lack of systems thinking and the vast incompleteness of the manifesto and our popular frameworks in the pursuit of simplicty causes this. We should be striving for sufficient.

8

15 Comments

The Agile Translator: 10 Terms to Transform Your Business Conversations They don't get it. You're talking about sprints and MVPs, and they're hearing about rushed work and cut corners. But what if... What if we could change the conversation? What if we could make them lean in instead of push back? Here's a secret: It's not about changing what we do. It's about changing how we talk about it. 10 translations that might just change everything: 🌊 "Agile" → "Adaptive" Negative interpretation: "Constantly changing direction without a clear plan?" Positive reframe: "Flexibly responding to market demands and opportunities for competitive advantage!" 🚀 "Minimum Viable Product" (MVP) → "Earliest Deliverable Product" Negative interpretation: "We're paying for less?" Positive reframe: "We get what we need sooner!" 💎 "Minimal Releasable Features" → "Soonest Valuable Release" Negative interpretation: "You're cutting corners?" Positive reframe: "We're prioritizing the most impactful features!" 🎯 "Limit Work in Progress (WIP)" → "Maximize Focus on Priority Items" Negative interpretation: "You're doing less work?" Positive reframe: "We're ensuring efficient delivery of key objectives!" 🔄 "Sprint" → "Delivery Cycle" Negative interpretation: "Why are you rushing?" Positive reframe: "Regular, predictable value delivery!" 👥 "User Story" → "Customer Needs" Negative interpretation: "Are we just guessing what customers want?" Positive reframe: "We're addressing real, specific customer requirements!" 🏗️ "Technical Debt" → "Quality Debt" Negative interpretation: "Why are we talking about finances in tech? Did we borrow money for these features? What does this even mean?" Positive reframe: "We're highlighting areas where product quality needs investment!" 🔍 "Product Discovery" → "Due Diligence"* Negative interpretation: "Why are we still discovering? Shouldn't we know the product by now?" Positive reframe: "We're conducting thorough market and product research to mitigate requirement risks!" 🧪 "Validate Assumptions" → "De-risk Requirements" Negative interpretation: "You're just guessing and checking?" Positive reframe: "We're proactively identifying and addressing potential project risks!" ⚡ "Continuous Integration/Continuous Deployment" (CI/CD) → "Accelerated Value Delivery Pipeline" Negative interpretation: "What the heck does that mean????" Positive reframe: "Streamlined process for faster, lower-risk delivery of value to customers!" The words we choose create the world we see. Choose wisely. *Hat tip to Peter Dudka for the "Due Diligence" inspiration. #AgileTranslator #BusinessAgility #ProductDevelopment #AgileLeadership #TechCommunication #InnovationLanguage #AgileMindset #BusinessStrategy #SoftwareDevelopment #CorporateCommunication

19

4 Comments

The people who run Agile CoE's and Lean Agile Centers of Excellence have a difficult job balancing what is best for the organization. It may be tempting to scale up as much training as possible to educate everyone en masse. "if everyone just knew all the things... it'd be easier for the company to make progress being agile" ... It's also tempting to focus on leadership first. Senior leaders need to set the example. Say the right things. Reinforce the right behaviors. Put an end to older unhealthy behaviors. Teach middle managers how to support agile ways of working. And yet... this can take time. Because "we also need to build the value streams and figure out how we'll become a product-led organization and define the strategy" ... And it's more than tempting, but very popular to first work on "making teams awesome". Let's build up the scrum masters and product owners and get the teams to start working in an agile way before we "scale". By defining our agile point of view as a company, we can help those on teams feel more connected to our strategy and focus on value delivery not just the squeakiest wheels asking them to "build stuff" ... And yet ... if you've been on enough agile transformations you know there's something wrong with every single one of those three approaches. So what do you do? Every organization is different, so there's no clear answer. But what I can tell you is that you have to feel that out and find a way to create tight feedback loops so you can even think about possibly working on more than one of the three at a time. Just like learning to coach a single team we have to "meet them where they are"... Maybe the strategy should be to build a few model agile teams first. Educate *their* leaders so they're well supported. Build the training just in time as it's needed so this one corner of the organization has most of what it needs for your new model for success. Then evolve organically. Ask yourself frequently, "what would be the right best next thing to do NOW?" ... because it will inevitably change. And maybe very quickly. Consider the pushback in our industry on SAFe. Most coaches dislike it because it's misunderstood by executives, as if it's a defined roadmap to success... a way to "install agile at scale". (Nevermind the capital A capitalism) But even SAFe is not meant to be implemented all at once. Some of their success stories are "partial installs" at best. Companies need to decide what suits them. No single framework should be ever be absorbed and adopted wholesale, IMO. You have to think and know what you really need and why you need it. Maybe the right approach is something like the sentiments in the "Manifesto for Scaling Agility". A value based approach to adapting as you scale. Focus on building a shared understanding of the vision, organic growth over predefined structures, favor a high performing organization over any one team or part, and team empowerment up the chain over old policies. 🤷‍♂️ YMMV

26

8 Comments

"Capacity allocation" is a fiction when perceived narrowly as "$s we pay for time focused on X". Capacity in knowledge work isn't that simple. Your current "capacity" is dictated by your organizational structure, your tooling, your skill mix, the current health of products, the data/research you've done, the morale of the team, levels of debt, etc. A $ spent for time focused on X may look *very different* from a $ spent for time focused on Y. A team struggling with organizational chaos will have an actual capacity that is a small % of the theoretical capacity as understood by the payroll. Which is all to say that creating an executive level "betting table" at an organization of any size that misleads people into thinking you can "move the chips" or freely relocate capacity vastly oversimplifies the current state of things, and encourages all sorts of bad habits.

255

28 Comments

"Technical debt": Move fast and don't fix things "Agile development": Admitting you have no plan "TDD": Guessing the future, one test at a time "Open source": Asking someone else to fix it "CI/CD": Automating your mistakes into production "API": Asking someone else to do it "DevOps": The belief that more tools fix any problem "Microservices": Creating enough small problems to avoid one big one "Cybersecurity": Playing hide and seek with hackers "Serverless": Pretending servers don't exist until the bill comes "Scrum": Group therapy for being behind schedule "AI": Making it look like computers think, one if-else statement at a time "Gamification": Turning every task into a quest for points nobody wants Too funny not to propagate. H/T to Matt Watson and 👋🏼 Gilles Crofils

5

1 Comment

It's equally incongruous to say a team has to choose their own workflow but then have them adopt an immutable one at the approach level (e.g., iterations, cross-functional teams). The team's context, maturity, projects, products are going to change. And saying they can change things after they understand is equally incongruous because they are never taught how. Teams need to start out understanding and being able to adjust their approach. Scrum Masters and Agile coaches who can help teams do this will be in demand shortly, I believe. But you don't learn this by just learning one or two team approaches.

6

1 Comment