Nathan Ducasse’s Post

I spent a big chunk of my career around Scrum teams, doing marketing for a software development consulting company. I spent my days talking with software developers, Product Owners, QA Specialists, Machine Learning Engineers… I learned a lot about project management from them. You’ve probably heard of working in sprints or the Agile methodology, or the Scrum framework perhaps. But here’s a rule that stuck out to me out of all the various learning about how developers get projects done: ⏱️ Fix time, flex scope. In essence, never move deadlines—if unexpected obstacles occur, modify the scope to still deliver something within the promised timeframe. That way, you know you’ll be shipping consistently, even if the amount or quality of what you ship may change during rocky periods. I follow this rule often when I hit snags in my projects. And for you, this might influence the way you approach your own content calendar, your LinkedIn post schedule, or maybe even your workout plan. ---------- This was an excerpt from the latest edition of First Class Operations, my newsletter for agency operators. 🌐 Read the full web version here: https://lnkd.in/dhZPGHyU 💌 Subscribe here: https://lnkd.in/dxuzGNKp

A sprawling collection of insights I learned/was reminded of at Øredev two weeks ago... 😀 ⏰ Agile has no deadlines. You can't be agile towards changing circumstances and new information if you have a point in time when things must be done. Waterfall has deadlines, agile has not. 💥 A deadline without consequence is a goal. We may discuss what constitutes a consequence, but if the only effect of the project shipping two weeks late is to add less to the next sprint, then it's not a deadline. 🎙 As a speaker, always repeat any question you get from the audience. You have a microphone, they have not. You might have heard them, the half of the audience in the back did not. Audience: ... ... .. .. ... ? Speaker: To solve that we need to configure the semaphore to use 4 parallel tracks. 👩💻 The customer paying your invoice is not the end-user. Find the end-user and solve THEIR problem. Customer: This software needs to highlight any instances of double newlines. End-user: I wish I could import the daily reports directly instead of having to copy-paste every single one of them. (which is why there was double newlines from the beginning) ⌛ Simple things takes time. Functionality code is just the small part. To write good software you also need to write error handling code and security code. All three needs unit tests and integration tests. Then the codebase needs to be refactored to still be readable two months from now. And then it needs to be made maintainable... -You've been working on this for a week. Is it done yet? -No, still working on this tricky data integrity problem. -But the actual data calculation algorithm? -Was done before fika-break Monday morning. Also, [XKCD-1425] 💰 Make it easy to buy. Making the customer want your product is the hard part. Buying it should be hassle-free. Customer: OK, you convinced me. How do I buy it? You: Fill in this form. Scan it. Mail it to our sales department. They will send a login code. Then fill in the customer form on our web-page, using said code. Click "Buy". When the credit score inquire is approved... Customer: You know what? I'm not sure I need it anymore. ⚖ Optimization and Maintainability are opposing each other. Frameworks like .NET can be written very readable, but higher abstraction means less performance. Optimized code is fast, but very hard to read and understand. Which one is easier to read, debug, and change? var result = "Make me ALL lowercase".ToLower(); or char[] result = "Make me ALL lowercase".ToCharArray(); for (int i = 0; i < result.Length; i++) { if (result[i] > 64 && result[i] < 91) { result[i] = (char)(result[i] + 32); } }

Better #documentation leads to better #DeveloperExperience One of the core values in Agile work is “Working software over comprehensive documentation.” It’s a good mantra to live by, but some developers tend to take it a bit too far. Providing good documentation that teaches developers how to work with their software is just as important. In his blog post, Dan Grøndahl Glavind lists why good, clear, and concise documentation should be a top priority in #platformengineering and how to ensure you have just the right info to keep developers happy. This is definitely a must-read for anyone interested in the topic: https://efcd.co/3WdzoQ0

Of course I had to join Raquel Fialho 's #DrupalConEurope session on embracing #agile principles in waterfall environments. Having been in (and delivered) many agile and business agility sessions myself, I wanted to hear her perspective. If you're unfamiliar with agile, it's a project approach that breaks down project deliverables into smaller chunks and each chunk is worked on one at a time in 'sprints', testing and iterating as you go. Done well, it means a better end result for the client, which delivers on their prioritised needs, within their deadline rather than a half-built (or poorly-built) outcome that may never see the light of day. She suggests an approach based on a cycle of Reduce, Reuse, and Replace at its heart. This means: 1. Paring down the client's needs with them to ensure that each element is simplified to it's essential parts; 2. Reusing as many pre-built modules and elements as possible; and 3. Replacing only what you cannot get from existing modules/code. Raquel suggests that this CAN be done within a waterfall project contract. However, the potential for scope creep is always there so both clients and delivery teams need to keep a tight grip on what is to be delivered in the project. If you can do that, you will get a better product, which can be improved on as you go, and foster closer collaboration between client and delivery team. #DrupalCon24 #SystemSeed

Scrum anti-patterns can hinder web dev teams. Tackle issues like overcommitting & poor backlog management to boost efficiency. #AgilePractices #ScrumMastery #WebDevInsights Read Now: https://lnkd.in/dmY64vWz

Code Rewriting No More. Painful. Oftentimes avoidable. Costly. Did you know that developers spend roughly a third of their time rewriting code, many times because of poor product specification? Read more here and share your thoughts 👇 #developers #product #productmanagment

🚀 Imagine Donald Trump as a Scrum Master... 🧑💻 Ever wondered how a development team would function with Donald Trump as their Scrum Master? I think we’d be in for quite a ride! Here’s how he would describe his role and actions if he traded the Oval Office for team stand-ups. 😄 -------------------------------------------------------------------------------------- 🔄 Stand-Ups & Team Focus “Look, I know what everyone’s saying. They say, ‘Donald, you run the tightest sprints. Nobody’s ever seen stand-ups like this.’ If you’re not on task, folks, you’re gone. We’re securing the sprint backlog, no freeloaders!” ⏩ Workflow “Too many interruptions, folks. We’re taking back our workflow—we’re reclaiming it for real work, for real results.” 🐞 Tech Debt & Bug fixes “Bugs? We’re gonna destroy the bugs, okay? I’m talking the biggest, most aggressive bug-fixing you’ve ever seen. No more dragging them along like we’re some second-rate development team. We’re squashing them, folks. They’re gonna be out of here, believe me.” 🫰 Feature Prioritization & Scope Creep “Feature creep? No, no, no. Not on my watch. We’re gonna build the most secure MVP, folks. And if anyone wants to sneak in extra features without my approval? Let’s just say, there’ll be tariffs on those tickets. High tariffs. Probably the highest.” 🚀 Deployment Plan & Production Pushes “Listen, we’re gonna have the fastest deployments. I mean, no one’s seen CI/CD like this, believe me. Some people call it ‘continuous integration,’ I call it winning. And it’s all inside our team, domestic — no external deployment delays. We push code faster!” 🎁 Releasing New Features “We’re launching phenomenal features, and we’re doing it in record time. For every completed feature? That’s right, tax credits. You’re doing great work, and you’re getting rewarded. Nobody rewards developers like I do, folks.” ------------------------------------------------------------------------------------- P.S. This is purely satire, meant to bring some laughs. 😁

TECHNICAL PMs and PMs that are TECHNICAL >>>>>> Hey there, The above title is just my word coinage so you don't have to overthink it. Technical PMs are those with vast knowledge and deep expertise in engineering who then also could take on Product Management Jobs. 💪🏽 Most likely, they were once mobile, front-end, or Back-end Engineers who then transitioned into Product Management. Or they are currently in those roles are juggling with PM roles 😎 My focus for this post is however on PMs who ought to be technical.🫠 In what sense? 🤷🏾♂️ They are curious, interested, and willing to have a full idea of what their Engineering team is all about. They are willing to learn the engineering jargon and lingua not just for the sake of it but also to know the implications of these things. What impact will this make? 💫 📍Ease of communication with your team as a PM 📍Your Engineers will be glad to work with you 📍Less stress of convincing you as a PM on what's expected from their end 📍Better relationship 📍Your deliverables as a PM with the stakeholders are also impactful and convincing because you know what you are talking about. 📍And ultimately Increased productivity. As a PM you should be aware and know what the Engineering team is up to and what tools they work with. A few of what you should know; 🔹What programming languages, frameworks, and Libraries are been used both from the FE or BE perspective? 🔹⁠Infrastructures and Deployment tools This will be your cloud platforms, containers, and serverless computing tools. AWS and Azure are examples. 🔹 What database is used; Is it Mongo, MySQL, et al 🔹Networking and communication tools that call out the APIs and Websockets being used. Examples are REST, SOAP, and GraphQL 🔹Code Quality tools 🔹Monitoring tools like Grafana and Datadog 🔹 Development tools like GitHub, GitLab, or Bitbucket. This is the idea 😤 Every product team has a specific product engineering stack and peculiar names of tools they use. Your job as a PM is to find out, know, and be aware of these tools peculiar to your team. A quick tip: ☕️ Build a solid relationship with the Engineering Lead and it will be easy to catch up quickly. Your development team will appreciate you better when you can speak their language and communicate better. 😅 Let me know if this helps 😀 Until then….keep building ✌️ P.S Don't go about looking for Maria in your team 🤣 ( You will understand this as you watch the video attached to this content) #technicalPM #products #Engineeringlingua #communication #productteam #productmanagers

A product owner can increase his knowledge about software development through the following approaches: ⭐ Understand Software Development Processes - Learn about development methodologies like Agile, Scrum, and Kanban. ⭐Engage with the Development Team - Regularly interact with developers to understand their challenges and workflows. ⭐ Learn Programming Basics - Study programming fundamentals, even if at a high level, to understand developers' language. Explore beginner courses in languages like Python, JavaScript, or Java on platforms like Codecademy or freeCodeCamp. ⭐Understand System Architecture - Learn about how software components interact, including backend, frontend, databases, and APIs. ⭐Study Software Design Principles - Gain knowledge of core principles like SOLID, DRY, and KISS to understand good design practices. Learn about technical debt and strategies for managing it. ⭐Explore DevOps Concepts - Understand the basics of CI/CD pipelines, version control (e.g., Git), and deployment practices. ⭐ Read Technical Documentation - Practice reading API documentation, system design documents, and technical specs to familiarize yourself with technical terminology. ⭐Participate in Code Reviews - Sit in on code reviews to see how developers ensure code quality and adherence to standards. ⭐ Follow Tech Blogs and Communities - Stay updated on trends by reading blogs like Martin Fowler, Dev.to, or Medium's tech publications. Join forums like Stack Overflow and Reddit to learn from real-world problems and solutions. ⭐ Take Software Development Courses - Enroll in online courses and Focus on areas like software architecture, development methodologies, or specific frameworks. ⭐ Work on a Small Project - Collaborate with the development team on a small side project or feature. Experience hands-on what goes into building, testing, and deploying software. ⭐Understand Testing and QA - Learn about the different types of testing (unit, integration, and end-to-end) and their importance. Explore tools like Selenium or JIRA for tracking and testing. ⭐ Learn Database Basics - Understand how data is stored and managed, including SQL queries, schema design, and database types (e.g., relational vs. NoSQL). ⭐Explore Open Source Projects - Contribute to open-source projects or review their codebases to understand real-world development.

𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗦𝗽𝗿𝗶𝗻𝘁 𝗧𝗲𝘀𝘁𝗶𝗻𝗴: 𝗔 𝗦𝘁𝗲𝗽-𝗯𝘆-𝗦𝘁𝗲𝗽 𝗚𝘂𝗶𝗱𝗲 🏃♂️💻 Day 114 of my 365-day blogging challenge! 🎉 Effective testing within a sprint is key to delivering high-quality software. Here’s a concise guide to help you plan: • 𝗗𝗲𝗳𝗶𝗻𝗲 𝗢𝗯𝗷𝗲𝗰𝘁𝗶𝘃𝗲𝘀: Clarify what you want to achieve. • 𝗖𝗼𝗹𝗹𝗮𝗯𝗼𝗿𝗮𝘁𝗲 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗧𝗲𝗮𝗺: Engage developers and stakeholders. • 𝗣𝗿𝗶𝗼𝗿𝗶𝘁𝗶𝘇𝗲 𝗧𝗲𝘀𝘁𝘀: Focus on high-risk areas first. • 𝗔𝗹𝗹𝗼𝗰𝗮𝘁𝗲 𝗥𝗲𝘀𝗼𝘂𝗿𝗰𝗲𝘀: Ensure the right tools and people are in place. How do you approach testing in your sprints? Let’s exchange strategies! 💬 Dive deeper into the planning process here: How to Plan Testing Within a Sprint https://lnkd.in/d22StYXa #AgileTesting #SoftwareQuality #SprintPlanning #QualityAssurance #Collaboration #TestingStrategy