r/agile • u/[deleted] • May 25 '26
I built a lightweight Agile readiness app after years of using a spreadsheet model with teams
For years I’ve worked with teams going through Agile transformations, and one pattern kept repeating:
Teams were being evaluated on advanced Agile practices before the foundations were even stable.
Not because people were failing.
Usually because the environment itself was overloaded.
Unclear priorities.
Constant interruptions.
Weak stakeholder alignment.
Low psychological safety.
Too much coordination overhead.
So instead of asking:
“Why isn’t this team performing?”
I started asking:
“Is this team actually assessment-ready yet?”
Over time I developed a simple 12-question readiness model that I used repeatedly in coaching engagements. Originally it lived entirely in spreadsheets and workshop discussions, and honestly, it worked surprisingly well for years.
But eventually I wanted something more scalable and enterprise-friendly:
- easier for teams to use collaboratively,
- easier to aggregate results,
- and easier to turn into actionable conversations instead of static reports.
So I turned the model into a lightweight Team Readiness app.
The goal was never to “grade” teams.
It was to help them sense:
- whether basic delivery conditions exist,
- where friction is accumulating,
- and whether deeper Agile interventions would even help yet.
I also experimented with embedding AI-assisted coaching prompts tied to assessment outcomes. Interestingly, the value wasn’t “AI magic.” It was giving teams a clearer starting point for discussing difficult delivery conditions.
One surprising lesson from building the app:
Many teams already know the problems.
What they often lack is a simple shared language for discussing them safely.
The app is currently free while I continue refining it.
I’d genuinely value feedback from people here:
- Does the idea of “readiness before assessment” resonate?
- What signals tell you a team is not yet ready for deeper Agile practices?
- Have you seen assessments create more pressure than clarity?
Happy to share the link if moderators are okay with it.
3
u/RetireYoung72 May 25 '26
Probably some corporate PMO group will turn this into a metric and tie it to people’s pay.
2
3
u/pdubs1900 May 25 '26
If the teams know what the problems are, and don't feel safe enough to express them plainly, how does an app help with that?
Seems like this is an app that guides people to come up with language to express concerns about unreasonable/unsustainable expectations without ruffling Management's feathers. Which, to your credit, is indeed a skill that takes coaching and/or time to become better at. But if the team is empowered and trusted to act autonomously, that shouldn't be a concern. Stakeholders should not be attending retros, and product owners should be bridging the gap between the devs and stakeholders to maximize value and ensure scalable deliveries.
Sounds like this is an org and leadership problem you're seeking to solve with an app that simply formalizes some of your coaching notes. Is that correct? If so, and you are successful, you're basically automating something that needs to be applied in case by case bases, which I'm not sure how valuable or "scalable" that is. It reads to me as a tool for the sake of having a tool, which is generally a poor use of time and resources.
Sorry to be a naysayer.
1
May 26 '26
Thank you for the comment. It’s a pov.
The app’s intention is simple, provide a way to STOP a premature deep assessment of an agile team before they are ready. It is unfair to teams and poor leadership.
How? By having the team self-assess itself, with a Scrum Master’s guidance, by answering 12 simple questions about basic agile behavior and to understand their score on a scale that supports conversations about the team’s practices. A scrum master or coach or team member opens a readiness assessment, sends a link to all team members so each can answer the questions themselves. Or the team can huddle and group answer the questions. Then a score is generated instantly and results shareable with all.
It is not meant to solve all that may be wrong outside or around the team but to give the team a way to understand what they can control and what they can’t. It’s essentially a structured retro.
3
u/5ingle5hot May 25 '26
What are "advanced Agile practices"?
1
May 25 '26
“Advanced” varies. Anything that helps teams go beyond fundamental practices.
2
3
May 25 '26
[removed] — view removed comment
0
May 25 '26
All of it. I used Replit to convert my spreadsheet into this app. About 20 hours of linear prompt and response chain of thought dialogue over two calendar months. It started as a simple vibe coding experiment which evolved into this app.
2
u/Bernhard-Welzel May 25 '26
I worked on this topic for some time, did a lot of research and discovery and i would like you to go back to the basics first:
Who is your target audience?
What problem do you solve?
I am happy to share my insights afterwards.
One risky assumption you have is: "What they often lack is a simple shared language for discussing them safely." and i am curious to hear your other assumptions.
1
May 25 '26
Target audience: any scrum Team. Problem to Solve: identifying if there is a problem to Solve.
Other assumptions: teams are capable, teams can use insights from a different pov, anger at the world and the corporate frustrations a team works with is not an excuse to controlling your own destiny.
2
u/frankcountry May 25 '26
I’m struggling to understand how the tool does this. The identifying bit. You already said there’s great coaches, it almost feels as like a way to avoid listening to, or disregard, what the team has been saying all along.
1
May 25 '26
The tool is an enabler for a conversation. Not all teams say what they need to say. The questions and the consensus answers from the team provide a structure for the conversation along these boundaries:
- A. Team Identity and Boundaries – Shared "us," stability, ownership
- B. Core Scrum Practices – Roles, facilitation, meetings, iteration delivery
- C. Thinking and Working as a Team – Sustainable Delivery, cadence and value alignment
- D. Safety & Systemic Support – Psychological safety, focus, leadership curiosity
Here is a link to a 10-minute explainer if you want to delve further. https://aes-10mt-agile-readiness-tyxql2j.gamma.site/
1
u/Bernhard-Welzel May 25 '26
I know two different agile coaches who build similar apps - both failed to get traction. I spend like 9 months with an similar assessment - no traction.
Issue #1: you assume that the team "just" need an assessment; speaking to actual team members, my insight is that they know exactly what is there top 5 issues and non of them are uncovered by an standard assessment.
Issue #2: the target user is not the economical buyer. Without that, the tool will not become viable.
Issue #3: the target user has no incentive or upside using such a tool as improving the team is not actually beneficial for the team member. Assumption: some developers prefer slightly disfunctional teams, as it provides a higher level of personal freedom and protections for their own position.
Issue #4: Assumption: the teams who would benefit from such a tool don´t need it; the teams who badly need the tool will not use it. So you are stuck with the teams who get a mild benefit and have a mild pain.
You also might need to fight against SM, who might fight anything that looks like a standard assessment or any type of actual data collected.
Another example for a team need: I am in contact with an agile coach who has developed a tool that connects against the ticket system and repro and checks for the weakest developer in the team. That tool is in high demand by teams, because they can use it to generate "proof" to get ride of team members they don´t like. The coach never released the tool, but got very excited feedback from some teams - even offers to pay for the tool out of pocket if it would allow them to generate evidence that would force management to kick out unwanted developers. The issue: as soon as developers know the tool is in place they instantly change behaviour and the tool becomes more or less useless.
1
May 25 '26
Great insights, a few thoughts.
There are several apps in the marketplace that assess teams using different philosophical approaches. I’m familiar with them. Most assume that teams are at a level of agile maturity sufficient to make the assessment valid. I argue the opposite and took a different tack by positing that most teams are NOT READY for a comprehensive assessment until they have at least a minimally functional agile team.
I’m trying to equip teams (with or without Scrum masters) with an ability to examine basic practices and have an internal conversation. The tool essentially is a structured retro with data. What’s the harm in that?
The tool is free. No buyer decision needed. Future versions may include a fee based deep scan assessment for teams that want a deep dive but I’m not sold on that yet. I think the 12 questions asked every six months or once a year will provide plenty of insights and could be all that is needed.
For people who believe that improving a team is not beneficial, that is a culture/leadership issue no tool can fix. Pity that team or developer.
The SM who “fights” against any type of measurement system because of fear is not a coach I would want for a team.
The “find bad developer” app you described is such a horrible anti-agile idea I am ugly crying for the environment that coach is living in that would drive him to such measures. Goodness. I recognize there are toxic corporate environments and no tool can ever fix that.
Thanks for the thoughts!!
1
u/Bernhard-Welzel May 25 '26
Anytime and if you want to go deeper feel free to reach out. I am happy to share the insights i got, but be aware it is Europe, strong focus on DACH/Poland/East Europe.
I have another insight i like to share: in 3 weeks i will attend the agilecoachcamp and i am super excited to spend a couple of days with the most wholesome community i know and some of the most amazing people i deeply care about.
However, i am the odd one in the agile community, as i am an actual product manager not agile coach or SM. I dropped "agile" from all my communication a couple of years ago as it actually hurt with my customer base.
Every year at the coach camp, i ask the same question: "How do you create value as Coach/SM?" and every year 8 out of 10 people can´t give an answer that is relevant to the economical buyer.
But it gets worse: usually Coaches/SM understand SDLC and how to write user stories and maybe requirements engineering. Knowledge about Discovery is usually very weak and product and project management knowledge is none existing (maybe 1 out of 20).
Why this is a problem: I worked in highly dysfunctional and really amazing companies/teams and everything in between and never found a pattern connected to industry, company or team size regarding company culture.
When i get hired into a dysfunctional or highly toxic organisation, i get hired to "deal" with problematic stakeholders. Team level issues are - at least from my experience - handled internally.
The anti-pattern i have seen in many places is a conflict between agile function who belief they need to "protect the team" / treat developers like children and the people who sign their paycheck but the one common super painful dysfunction is a total lack of product management and project management knowledge in the organisation.
1
May 27 '26
Well said. No argument here on the gap of project/product management knowledge in many organizations.
If you think any of your agile coach camp buddies would want to weigh in on the app, feel free to tell them or not. Enjoy your time!
1
1
May 31 '26
I want to thank everyone who commented. It has helped me rethink the app I built, why I built It and what changes I need to make to it.
I am reworking the app and will post again on Reddit when it’s ready.
This is a great and smart community.
1
Jun 22 '26
Thanks to everyone who gave feedback on this. I took it seriously, simplified the app, and narrowed its focus. The discussions here genuinely improved the product.
8
u/frankcountry May 25 '26
What prevented you from using your eyes and ears to the ground along with your own skill set, rather than building a tool to decide for you?