The ideal agile project doesn't start with a framework. It starts with stakeholders who shows up.

Not one who sends requirements and disappears. One who joins planning, gives feedback every iteration, and helps define what's valuable.

We tried both. When stakeholders vanishe, you're guessing. When they're in the room, you're building the right thing.

The biggest risk in any project isn't technical. It's a silent stakeholder.

#agile #softwaredevelopment

Alt...

YOUR BIGGEST PROJECT RISK? A SILENT STAKEHOLDER.

How can you assess business value when outcomes are uncertain?

Business Value Floor 95 represents the 5th percentile of 100,000 simulated outcomes.

Consider prioritizing utility over profit (dm), leveraging Team Topologies' platform to enable teams, and recognizing the $8.8 trillion in demand-side value of open source.

➡️ https://www.eifel42.dev/post/business-value/

#BusinessValue #ProductOwner #ValueAtRisk #Agile #SoftwareDevelopment #OpenSource

Alt...

Business value distributions for the three feature hypotheses

"When will the project be done?"

Wrong question. A product is never done, you just stop investing in it.

The real question is: What's the smallest version we can ship that actually works end-to-end?

Not a prototype. Not a mockup. A real thing a real user can use.

Then ship it. Learn. Plan the next version. Repeat until the budget runs out or the market moves on.

#agile #softwaredevelopment

Alt...

WHEN WILL IT BE DONE? WRONG QUESTION.

Roadmaps create certainty illusions—outcomes are unpredictable.

Feature Hypotheses Simulation with Monte Carlo and Jupyter helps product owners estimate value, risk, portfolio balance, and assumption impact.

Not about perfect prediction: focus on discussing uncertainty before investing.

https://eifel42.de/post/feature-hypotheses-simulation/

#ProductOwnership #Agile #RiskManagement #MonteCarlo #JupyterNotebook #Python #SoftwareDevelopment

Measuring the wrong thing

Process improvement requires measurements. How do you know what to improve if you can’t see where things aren’t working, and how do you know you’ve made the right change without seeing those numbers going in the right direction?

But measuring doesn’t mean you’re measuring the right thing, and measuring the wrong thing can lead to the wrong outcomes, and can be very harmful (see Liz Keogh’s talk on perverse incentives )

The key to the success of any metric is that it is owned by the team so they have complete control over the changes needed to affect it, so they feel ownership, and that improving the metric has a useful business outcome.

Metrics that I’ve found useful in the past include:

Number of bugs introduced by a release.

This is a tricky one to work with because it can easily be a perverse incentive, and the feedback cycle can be slow, especially with the usual 6-12 month release cadence. However, on one waterfall project I took over there was a strong negative perception of the quality of the code, and big count was a useful proxy as the customer had access to JIRA so the big list was already visible. Reducing this number was a combined effort where testers and developers had to approve requirements, developers and testers invested in automated testing at all levels, and testers joined the developer daily stand-up in order to catch bugs before they were released “have you checked that page in Welsh?“, “We found problems on that page last time because IE was too slow“.

Number of releases per month.

On an agile project we noticed that releases were getting held up because testing was slow and produced a lot of rework, which were then tested against more features that had been pulled from the backlog, increasing testing time. Each release also took half a day, so we had to schedule them carefully.

So we set a goal of focusing on releases for a month and measuring how many we did. There were other measures within that, such as monitoring work in progress on the testers, time taken to do a release, and cycle time from start of development to live release, but they all drove the big number, visible to the whole company, of more quality releases.

Questions answered per day.

This can be a very useful metric for research projects, especially when following a fail fast approach, when you want to prove something can’t be done before you invest in doing it. In order to do that, you need lots of questions with quick answers, to accelerate learning. Any answer, positive or negative, is progress. It means we have learned something.

“I cheerily assured him that we had learned something.
For we had learned for a certainty that the thing couldn’t be done
that way, and that we would have to try some other way.” – Thomas Edison

Age of Pull Requests

Successful agile projects rely on peer review, either via pairing, or a formal review process such as git PRs (and I won’t discuss that in this post). However, when we started working with these on one project, we discovered that we were building up a large debt of Work In Progress because the team wasn’t incentivised to review each other’s code, so one of the developers set up a nag bot for any PR older than 4 days. It lasted 2 weeks before it was no longer needed.

What about you?

What metrics have you used to incentivise the team? What problem were you trying to solve, and did the metric work?

RE: https://mastodon.social/@lisihocke/116617064083687225

If you haven't taken that workshop, now is your chance. It was one of the best I ever attended. By one of the best trainers and speakers I know.

#elbsides #security #softwaredevelopment

Claudius Link boosted

Lisi Hocke [she/her] » 🌐 2026-05-22
@lisihocke@mastodon.social

#elbsides2026 is coming up soon! 🤩 Want to join me? There are still tickets left for my workshop "Secure Development Lifecycle Applied - How to Make Things a Bit More Secure than Yesterday Every Day": https://www.elbsides.eu/2026/workshops/#secure-development-lifecycle-applied---how-to-make-things-a-bit-more-secure-than-yesterday-every-day Wondering what you can do to improve your product's security posture, step by step, that neatly fits into what you're doing already? Then this session offers you just the space to practice together and gain hands-on experience. See you at @elbsides! 😎

Your CTO put #DORA metrics on a company dashboard. Now teams are competing on deploy frequency.

They're shipping garbage faster.

DORA metrics are a mirror for your team, not a scoreboard for management. The moment you turn them into KPIs or compare Team A to Team B, you've killed their purpose.

Good numbers don't mean good software. They mean you have something worth investigating.

#softwaredevelopment #agile

Alt...

DORA ON A DASHBOARD? YOU'RE HOLDING IT WRONG.

Want to level up your engineering career? Adopt a Product Thinking mindset!

Learn how product management principles can help your engineering team deliver more impactful results, build empathy for users, and take greater ownership of what you build.

🎬 Watch the #InfoQ video by Stéphane Di Cesare & Cat Morris ⇨ https://bit.ly/4eUWnZp

📄 #transcript included

#Culture #ProjectManagement #Agile #SoftwareDevelopment

New post: Scrum is Dead

“We tried Scrum.”

A few meetings.
Some tickets.
New role names.

Everything looked familiar.
Nothing actually changed.

#Agile #Scrum #RealityCheck #SoftwareDevelopment #Leadership

https://agile-is-a-state-of-mind.com/scrum-is-dead/

Your team shipped 47 tickets last sprint.

How many of them made your customer money? Or saved them money? Or reduced risk?

If you can't answer that, you're not delivering value. You're delivering activity.

Agility isn't about throughput. It's about asking one question before every iteration: "What's the next thing that creates real value?"

Stop counting tickets. Start counting impact.

#agile #softwaredevelopment

Alt...

47 TICKETS SHIPPED. ZERO VALUE DELIVERED.

Remember a government RFP some time ago. 60+ pages of contradictory requirements, a fixed-price contract, and zero budget transparency.

The cherry on top? "The goal is agile project management."

You can't put "agile" in a waterfall document and call it a transformation.

#agile #softwaredevelopment

Alt...

AGILE RFP IS AN OXYMORON

RE: https://mastodon.social/@ewolff/116602128910728061

Großartige Folge, lohnt sich!!

#agile #softwaredevelopment #softwareengineering #softwarearchitecture #Softwarearchitektur

Eberhard Wolff » 🌐 2026-05-19
@ewolff@mastodon.social

John Romeros Prinzipien mit Tom Asel
#SoftwareArchitektur im #Stream
Aufnahme (Video / Podcast) verfügbar!
https://software-architektur.tv/2026/05/15/episode312.html

Joshua Angolano, CPCU presents '360° Agile: Seeing the Whole Picture' this July at Nebraska.Code().

https://nebraskacode.amegala.com/

#Agile #SoftwareDevelopment #EngineeringTeam #TechConference #LeanTECHniques #SoftwareEngineering #PracticalAgile #AgileLNK #LincolnNe #ProjectManagement #Stakeholders #DevConference

Yesterday, I participated in a training on implementing agentic software development lifecycles; we are now entering "Probabilistic Pinball Machine" times in #SoftwareDevelopment, where we constantly set up, evaluate and update organization- & product-level, domain- & craft-specific expectations as "bumpers".

"Development" is then playing your Pinball with your hands on your back most of the time, observing the number of $$$-Chings draining your budget, ...

Welp. I've been using GitLab for over a decade and have been pretty happy with it. Deployed and maintained several instances, some personal, some for small hobby orgs, some for work.

But it looks like it is time to ditch GitLab for good:

> Software will be built by machines, directed by people. AI is the substrate on which future software gets built. Agents will plan, code, review, deploy, and repair.
https://about.gitlab.com/blog/gitlab-act-2/

#GitLab #AI #FuckAI #SoftwareDevelopment

Dea Mandery presents 'Practical tips to break work down and deliver twice as fast' this July at Nebraska.Code().

https://nebraskacode.amegala.com/

#PracticalAgile #DeliverySpeed #Shipping #SoftwareDevelopment #Agile #womenintech #WomenInSTEM #womenwhocode #projectmanagement #TechConference #Heartland

New 📚 Release! Spec-Driven Development: Construye con IA sin Perder el Control by Bezael Pérez

Usar IA para programar es fácil. Usarla sin perder el control, no tanto. Spec-Driven Development es el método para convertir tu idea en una spec que la IA ejecuta con precisión — sin loops infinitos, sin código roto, sin empezar de cero.

Find it on Leanpub!

Link: https://leanpub.com/sdd-spec-driven-development

#books #programming #softwaredevelopment #ai

Keil Wilson presents 'Prepare for Agility: Conditions That Make Agile More Effective' at Nebraska.Code() this July.

https://nebraskacode.amegala.com/

#PracticalAgile #Agile #AgileTeams #Workflows #ProjectManagement #sprint #DevWorkflow #AgileLNK #softwaredevelopment #PMI #technology #TechCareer #TechTeam

Joshua Holland presents 'Tackling Technical Debt with the Mikado Method' at Nebraska.Code() this July.

https://nebraskacode.amegala.com/

#Codebase #TechnicalDebt #Refactoring #LegacyCode #Programming #MikadoMethod #SoftwareCraftsmanshop #NebraskaTech #GreatPlains #softwaredevelopment #CodeCommunity #TechTrends #programminglife #networkingevent #analysisparalysis #Nebraska

Can you FEEL it? ⚡ The energy is building! DevConf 2026 is bringing together the best minds in South African software development. Innovation. Collaboration. Community. It's almost time! #DevConf2026 #DevExcellence #SoftwareDevelopment

Software Development is full of uncertainty, yet many planning approaches pretend otherwise.

In her session at Nebraska.Code(), Jodi Jones focuses on practical ways to:

• Understand different types of problems
• Plan across varying levels of uncertainty
• Communicate clearly even when outcomes aren’t fixed

Featuring models like the Cynefin Framework and Known vs Unknowns.

https://nebraskacode.amegala.com/

#Agile #SoftwareDevelopment

It really feels like AI assisted or agentic software development amplifies the issues you have in the process. Have a team which works well together, is self-organised, is empowered and has already learned how to collaborate it aids as a tool or a new methodology.

Take a team where this is not the case, couple it with duedates and pressure and you unleash chaos.

#ai #softwaredevelopment

I'm looking for problems by watching you CI server build jobs and telling the devs if a build breaks. (Don't asks about the broken e-mail notification)
I don't call it #QualityEngineering or similar. Just plain / upland #Testing .

#RapidSoftwareTesting goes beyond the execution of predefined scripts and also doesn't reinvent the wheel.
Good, deep testing is doable.

#quality #softwaredevelopment #softwaretesting #agile #kanban #scrum

Tools like Claude Design have an assumption baked into them: that "productivity" is fungible, and more "productivity" of artifacts leads to more value.

But if anything, the problem is that there are too MANY artifacts — and decision-making within your company begins to take on a "garbage can" model.

The solution for designers is to step out of clock time work, and think on calendar time.

https://productpicnic.beehiiv.com/p/claude-design-is-a-clock-time-solution-for-a-calendar-time-problem

#UX #UXDesign #AI #LLM #tech #softwaredevelopment #design

Barry Stahl, Jason Erdahl, MBA, David Handlos & Joshua Holland present on Software Craftsmanship this July at Nebraska.Code().

https://nebraskacode.amegala.com/

#TechnicalDebt #MikadoMethod #Refactoring #ShortTermFixes #Tech #CareerProgression #DevOps #SREs #Metrics #FNBO #softwaredevelopment #softwareengineering #technologynews #TechConference #programming #Coding

#InfoQ dives deep into #SpringFramework 7 & #SpringBoot 4 with the team behind the code.

🛠️ Key Focus: the shift toward core resilience by integrating features such as retry and concurrency throttling directly into the framework, alongside the performance benefits of modularizing auto-configurations.

🔗 Read now: https://bit.ly/3OIoz6W

#Java #AIcoding #Microservices #SoftwareDevelopment

Interesting view on agile development and how LLMs are changing it.

https://lewiscampbell.tech/blog/260414.html

I specifically liked this:

«One unambiguously positive development that's followed is that software professionals are writing specs again. [...] Agile told us "Working software over comprehensive documentation". Spec-Driven Development is telling us "Comprehensive documentation creates working software"»

#softwareDevelopment #agile

New video: McLuhan's "the medium is the message" applied to AI-assisted development.
Not prompt tips. Ways the tool is already changing how developers think — articulation, abstraction, verification, documentation, code structure.
🎥 https://mozaicworks.com/blog/the-medium-is-the-message-what-ai-really-does-to-how-you-code?fsp_sid=1300 #softwaredevelopment #programming #AItools #video
https://mozaicworks.com/blog/the-medium-is-the-message-what-ai-really-does-to-how-you-code?fsp_sid=1300

New 📚 Release! Spec-Driven Development: Construye con IA sin Perder el Control by Bezael Pérez

Usar IA para programar es fácil. Usarla sin perder el control, no tanto. Spec-Driven Development es el método para convertir tu idea en una spec que la IA ejecuta con precisión — sin loops infinitos, sin código roto, sin empezar de cero.

Find it on Leanpub!

Link: https://leanpub.com/sdd-spec-driven-development

#books #programming #softwaredevelopment #ai

Joshua Angolano, Teresa Hill-Rush, Jon Graf & Sarah Little present on Practical Agile this July at Nebraska.Code().

https://nebraskacode.amegala.com/

#PracticalAgile #SoftwareCraftsmanship #ANNIEModel #Agile #Nebraska #SoftwareEngineering #SoftwareDevelopment #Programming #WomenWhoCode #WomenInSTEM #HeartlandTech #Midwest

LLMs have no concept of "true" or "good." But they are trained to signal high-quality work. Meanwhile, bosses are pressuring workers: go faster, produce more, let the AI cook.

Study after study documents what this does to the human brain: cognitive surrender. We're "in the loop" but the bot calls the shots.

Read more in this week's issue of the Product Picnic newsletter:

#LLM #AI #UXDesign #tech #softwaredevelopment #software

https://productpicnic.beehiiv.com/p/ai-mandates-are-a-demand-for-cognitive-surrender

The Meta-Engineer - 10x Was the Floor: Building Autonomous AI Systems with Claude Code by James Phoenix is the featured book on Leanpub!

Link: https://leanpub.com/the-meta-engineer

#books #coding #claudecode #softwaredevelopment #softwareengineering #ai #vibecoding

If you don’t have the resources to write and understand the code yourself, you don’t have the resources to maintain it either.

Any monkey with a keyboard can write code. Writing code has never been hard. People were churning out crappy code en masse way before generative AI and LLMs. I know because I’ve seen it, I’ve had to work with it, and I no doubt wrote (and continue to write) my share of it.

What’s never been easy, and what remains difficult, is figuring out the right problem to solve, solving it elegantly, and doing so in a way that’s maintainable and sustainable given your means.

Code is not an artefact, code is a machine. Code is either a living thing or it is dead and decaying. You don’t just write code and you’re done. It’s a perpetual first draft that you constantly iterate on, and, depending on what it does and how much of that has to do with meeting the evolving needs of the people it serves, it may never be done. With occasional exceptions (perhaps? maybe?) for well-defined and narrowly-scoped tools, done code is dead code.

So much of what we call “writing” code is actually changing, iterating on, investigating issues with, fixing, and improving code. And to do that you must not only understand the problem you’re solving but also how you’re solving it (or how you thought you were solving it) through the code you’ve already written and the code you still have to write.

So it should come as no surprise that one of the hardest things in development is understanding someone else’s code, let alone fixing it when something doesn’t work as it should. Because it’s not about knowing this programming language or that (learning a programming language is the easiest part of coding), or this framework or that, or even knowing this design pattern or that (although all of these are important prerequisites for comprehension) but understanding what was going on in someone else’s head when they wrote the code the way they wrote it to solve a particular problem.

It frankly boggles my mind that some people are advocating for automating the easy part (writing code) by exponentially scaling the difficult part (understanding how exactly someone else – in this case, a junior dev who knows all the hows of things but none of the whys – decided to solve the problem). It is, to borrow a technical term, ass-backwards.

They might as well call vibe coding duct-tape-driven development or technical debt as a service.

🤷‍♂️

#AI #LLMs #vibeCoding #softwareDevelopment #design #craft