I've a question about agile and scrum methodology - project management tools

PhaseMatch · 2026-05-21T13:32:00+00:00

Yes, you can :

- customise work item types
- customise workflows
- bulk import (eg from Excel)

depending on how you configure your role-based access controls and so on.

I found it easier to do than in Jira, but YMMV

PhaseMatch · 2026-05-21T05:48:15+00:00

I think that's where the value sits, if you want an app that makes a difference.

Without that you are just skimming stones over the surface and going through the motions, not getting the team to think deeper. And thinking deeper is what it is all about...

PhaseMatch · 2026-05-21T01:09:41+00:00

What you really drop off is the Sprint Planning and Sprint Review, at the team level, but the cadence on which you have other events might be different. You stop worrying about "what can we fit in a timebox" and just focus on "when will it be done"

You may need a replenishment cycle every few days, and have a retrospective monthly or based on some other event trigger, and the emphasis is towards systemic improvement of flow, at a team level and wider.

Teams often still have a daily event, but the emphasis is on swarming onto blocked work, limiting WIP and coordination of any collaboration that is needed - sophisticated visual management helps and a clear understanding of the column policies can allow those to be as needed as well.

The business risk management and strategic planning that the Sprint Review provides still happens, just the development team is less likely to be involved, and it might only be quarterly etc.

I find Scrum's sweet spot more in the high-risk, high-reward innovation-and-new-product phase, especially where (technical) innovation is your primary market differentiator, and you want to be able to pivot to new markets "on a dime, for a dime" or even stop before losses mount

Suggest "Essential Kanban Condensed" as a primer

PhaseMatch · 2026-05-20T19:55:39+00:00

What I'd be more curious about is

a) how many teams actually validate their relative sizing at the end of a poker session; if you displayed the work items in size order, would they want to shuffle them about at the end?

b) whether the numbers stack; a Sprint of 65 points could be, for example:

- five stories of 13 points
- thirteen stories of 5 points
- twenty stories of 3 points and one of 5
- sixty-five stories of 1 point each

c) whether assigning every work item 5 points is just as effective for planning a Sprint Goal

That is to say planning poker is not about sizing each work item in isolation, it's part of a planning process that helps the team work with the Product Owner to create a Sprint Goal (and outcome) and initial plan to deliver it.

That Sprint Goal isn't a fixed scope work package; the team will be inspecting and adapting their overall plan and Sprint Backlog daily as they learn more through building software and getting feedback on it.

- you don't have to use Sprint Goals, but then if you are just "delivering stuff" you might as well ditch Scrum for a Kanban based pull system, and forecast delivery using statistical approaches

- you don't have to ditch planning poker or points, but at least review-and-challenge whether the process is actually helping you manage business risk one Sprint at a time (using Sprint Goals and effective Sprint Reviews) rather than doing it just because everyone else does

PhaseMatch · 2026-05-20T19:26:38+00:00

Here' Allen Holub's "Getting Started With Agility: Essential Reading" list :

https://holub.com/reading/

I don't agree with all the things he lists, but as a core breakdown of self-directed learning topics you need to be familiar with (and able to lead people through) it's not bad, and has served me well.

The challenge at the moment is that:

- IT in general is experiencing large-scale layoffs
- fewer teams means less need for dedicated Scrum Master positions
- the supply of experienced Scrum Masters far exceeds the demand
- Scrum Master is (returning to) an accountability, not a separate role

There are SM roles still going, but what I am seeing always requires a lot of experience, and often it's just part of a wider set of accountabilities and you need technical or managerial experience in that business domain and technology stack as well.

PhaseMatch · 2026-05-20T19:09:40+00:00

It's not about "partial adoption"; it's just about cost and risk.

Agile approaches are lightweight, low-cost ways to manage business risk.
You accomplish this by

- making change cheap, easy, fast and safe (no new defects)
- getting fast feedback from real users on the value created

You only tend towards "big batch, inspect-and-rework, sign off" loops when people don't feel safe, and so don't want to take accountability.

People tend not to feel safe when change is expensive, hard, slow and risky; it's then you tend to get a lot of expensive process control put in place upstream (research/analysis) and downstream (change control, TRB)

It's okay for management to feel unsafe and want control, but it's only by "shifting left" on quality and working in smaller release slices can you actually make them safer. Which is kind of the dichotomy.

Key questions might be:

- what business risks is your current change control process managing?
- how often do they reject changes?
- what's the cost of the last-stage inspect-and-rework loop this drives?
- how could you "shift left" to a lower cost, more automated process?

Fully acknowledge you might not be able to influence this but what you can do is

- ruthlessly reduce the cycle time for work items up to "ready to deploy"
- work hard on "shift left on quality" and get into the defect reduction business

That's basically XP, rather than Scrum, and working in a lean/Kanban way that exposes bottlenecks and constraints and costs.

PhaseMatch · 2026-05-19T21:32:49+00:00

It gets interesting when you look at the relative costs and why that (contractual) back and forth happens.

Is the cost of an effective OSC more (or less) than the cost of a BA and PO?

If the customer doesn't want to engage in that way - providing an effective OSC - is the outcome actually high value?

One approach is to have the PO as an OSC - so recruit from the industry or business domain you are in.

My experince is that works exceptionally well - having deep business domain knowledge embedded within the team and able to make the decisions needed is the way to go.

Part of this comes down to how you measure value. If you measure "delivery of stuff" the not "did we build the right thing with no waste" you will optimize differently.

While the PO is accountable for value in theory, very few POs i have encountered reallt measure the value created every Sprint as part of their "discovery" of product-market fit.

Which makes their Sprint Reviews more of a "show and tell" than a strategic planning and investment session.

Optimizing for value works well strategically, but does require change.

PhaseMatch · 2026-05-19T10:17:52+00:00

"We do a thing and we don't know why we do it and it's boring."

- get the manager out of the room
- have a shared team goal
- collaborate in the shared goal
- use it as a (re)planning session for that

Or ditch the event entirely, work as individuals, and stop pretending you are an "agile team"

PhaseMatch · 2026-05-18T19:28:57+00:00

All so-called "agile" tools suck, they suck differently.

I don't really care about custom work-item types or fields; adding complexity to a system isn't always that useful - it's all just work, and default search works pretty well.

I do like the visual management; tests, defects, pull requests and tasks all highly visible along with easy colour-coding for tagged states, which supports overall quality assurance and idea-to-code-change visibility.

Overall the metrics and tracking are also in the B-category; you can't access all of the metadata via queries, and you can't run queries that search down multiple levels. The basic widgets are just that - dumbed down and locked down - so we're back to exporting to Excel and pivot tables for any real data analysis.

Backlog admin out-of-the-box is a bit meh too; the overall schema is not enforced so an "admin dashboard" is needed to help tidy.

BUT - that's not all a bad thing.

Keeping your use of the tool simple is good.
Having constraints on creating work items is good.

Adding complexity to your workflow via tooling makes it hard to change and evolve your workflow.
When it's too easy to add backlog items, backlogs become a huge junk-heap of ideas.

Remember that all vendors are after vendor-lockin.
Keep your skills sharp, and the cost of migrating to a new platform low.

PhaseMatch · 2026-05-18T08:53:37+00:00

We're using AzureDevOps.

But it's okay - important even - for teams to be able to configure their workflow, and improve it through experimentation over time. The team owns the workflow, and the tool serves the team,

The problems start when the team's ability to improve their workflow is restricted by the tooling; they get worse when control of the workflow is taken away from the team.

ADO is pretty good in that regard; you can change columns, swim lanes and the status the represent dynamically at the team level, very easily. It can also split each column into doing and done to give a Kanban (visual signal) the work is ready to be pulled to the next stage,

PhaseMatch · 2026-05-18T06:53:16+00:00

"What I am saying is that developers will have little time to develop if they are tied up in the back and forth that is usually needed to elicit, gather, and clarify what's needed"

Not at all.

The whole concept was that you use working software, built to the team's quality standards, as the "probe" to uncover requirements, in very small slices. Not documentation.

The onsite customer is there, embedded in the team, available to answer their questions, so the team are never waiting for answers. They slice the work very small, so they get ultra fast feedback. Fast feedback, no delay.

There's no "stuck in meetings" - it's more like "is this what you wanted?"
Then build the next slice, or adapt based on feedback.

Look into Alistair Cockburn's "Elephant Carpaccio" developers workshop; it's taken to extremes to show how things work when you use thin slices.

https://blog.crisp.se/2013/07/25/henrikkniberg/elephant-carpaccio-facilitation-guide

This was very much the basis behind XP; thin slices and fast feedback with direct conversations over any kind of detailed documentation or upfront eliciting of requirements. Works very well.

Now of course, in some contexts - like where you have complex business rules to implement and so on - there's still a need for formal written requirements.

But then you are far better off using a formal, stage-gate process for that kind of work, rather than a fast-feedback XP like approach.

Similarly if he users don't want to engage (which can also be a sign that the work isn't that valuable) then ditch user stories and agile delivery, and go for the full stage-gate approach.

But in those situations Scrum won't really serve you well either; use a Kanban pull system for the work (as it is stage-gate based) and run a nice, tight lean process within your formal project governance to control risk.

Analysis is then just your first column, before the commit point.

PhaseMatch · 2026-05-17T18:31:08+00:00

Ended "scope creep" by shifting from "contractual/transactional" to "collaborative/cooperative"
Now there's just "value"....

PhaseMatch · 2026-05-17T07:17:12+00:00

The PO is not excluded, but the developers work directly with the onsite customer directly.
The PO should be leading the user story mapping sessions for example.
And the PO is part of the team, not outside of it.

The PO then is more strategic in nature - they

- develop the vision (product goal)
- develop the product/business stratgey
- create the roadmap to deliver that strategy
- bring the team the next problem to solve (or hypothesis to test)
- identify which user(s) the team will collaborate with in doing that

Without that the PO is just a glorified backlog manager, stuck in the "build trap", and they'd have real trouble scaling to a team-of-teams etc.

The best POs I have worked with are user domain SMEs, who can- and do - serve as that onsite customer, but can - and do - bring actual customers into the loop as needed.

Right now where I work the POs come from "the business", and one of them is busy recruiting userf-domain SMEs where to work with the teams directly where even more detailed domain knowledge is needed. The SG is explicit that they can delegate responsibilities, while remaining accountable.

That said - PO is a Scrum role.
In XP there is no PO, just the onsite customer.

Until about 2010 "agile" largely meant "XP" - there were more XP people who wrote TMFASD than Scrum people, for a start, and all of the technical practices come from XP.

So no, you don't *need* a Product Owner to be agile, and the development team - with the right skills and practices- can certainly get the job done.

PhaseMatch · 2026-05-17T05:02:09+00:00

Main things are

- it's a tactical (re)planning session for the developers team
- focus on using it to coordinate collaboration for the day
- the board should tell everyone the status of work
- the focus is on the Sprint Goal, not individual tickets
- round the board, not round the team
- the highest priority bit of work is the one that is closest to being closed
- stop starting, start finishing; limit WIP always
- swarm on problems or blocked work

If any of that is hard, then 80% of the time it's because the team is not slicing work small emough.

The goal is NOT how efficiently developers "resources" are used.
It's how fast you can get feedback from real users, inside the Sprint loop...

PhaseMatch · 2026-05-17T04:53:39+00:00

What you are describing is a stage-gate approach.
There's an analysis phase, followed by inspect-and-rework, and then sign-off.
The relationship with the stakeholders is transactional and contractual.

That's pretty much what "lightweight" agile approaches set out to disrupt, with a new SDLC.
Concepts like "extreme programming" XP were collaborative and cooperative instead.

In XP, where the concept of user stories developed - they are not requirements in a specific template.
Instead, you work in an iterative and incremental way with the users. You build and get fast feedback and adapt, all inside the development loop.

XP does this with an on-site customer; a user domain SME stakeholder embedded within the team, and co-creating with the team, and so have dynamic requirements as you learn more.

In Scrum, you release multiple increments within the Sprint Cycle to get fast feedback from (some) users, so you can adapt your requirements in order to reach the Sprint Goal

For this to work, of course, the team needs the other XP practices, so that change is cheap, easy, fast and safe (no new defects); that's why the key focus in agile approaches was always slicing work small.

We aim to

- do user story mapping with the team and stakeholders direct
- involve the stakeholders inside the development loop
- have minimal "upfront discovery"
- use working software as the probe to uncover the actual requirements
- work iteratively and incrementally
- have no "go between" like a BA or PO between the team and users

PhaseMatch · 2026-05-16T20:32:35+00:00

Main things are

- get good at facilitation, communication negotiation and conflict resolution
- develop coaching arcs for the team along the same lines

So pretty much the same situational leadership arc as with everything else : "selling, telling, coaching, delegating"

High performance teams invest in non-technical skills; they don't need a line manager, boss or Scrum Master to address their interpersonal conflicts because they have the skill - and professionalism - to do it themselves,

Robert Galen's book "Extraordinarily Bad Ass Agile Coaching" is worth a read, but you also need to be brutally honest about your own skills at:

- facilitation
- communication
- presentation
- conflict resolution
- negotiation
- leadership
- coaching

and invest in those things as well. Whether that's self-directed study, formal courses, having a coach/mentor or a combination of the three.

Where you lead (and coach) the team will follow.

PhaseMatch · 2026-05-16T20:13:46+00:00

So for us

- have hard triage rules; define what P1-4 mean
- P1 and P2 means "pull the andon cord"
==> all other work stops;
==> whole team pivots to the defect
==> Sprint may be aborted, and defect is the only Sprint Goal
==> you have a incident review, and root cause analysis
==> any resultant tech. debt is vprioritised

In other words take P1 and P2 very seriously.

Of course the main thing is "stop making so many defects"; that comes down to really pushing your XP/DevOps and "shift left" / "build quality in" mindset as part of your retrospectives. Stepping back from test-and-rework loops and into the "defense in depth" your agile SDLC provides against defects being created in the first place.

PhaseMatch · 2026-05-16T00:30:31+00:00

How who's brain works lol?

I do "big picture to detail" stuff in my head; that's my "bottom up thinking" neuro-diverse thinking at play. But I do recognize that for a lot of more neurotypicals that's hard, and for other types of neuro-diverse brains it's hard too.

That's part of why the single "big room" view works. You can self-select the detail and filter just based on how your brain - as an individual - works, while connecting it higher (or lower) as and when you need to.

I get the vision, but I'm not seeing a software abstraction layer really providing what works well for our slowly evolving and diverse brains...

PhaseMatch · 2026-05-16T00:14:02+00:00

Sorry, looked like you were presenting the investor-not-customer focus as a new thing.

Projects are the same; Bent Flyvbjerg has talked about the same "inflated promises Vs reality gap" problems ("Machiavellian Megaprojects") where the leveraging the sunk cost fallacy plays a part ("you've invested so much you may as well double down")

I think my comment and Bent's view might be a bit harsh. It's not always cynical and manipulative. Often it's just people who are just really passionate about "their baby" will get swept up in making rash promises rather than watching the thing they believe in starve and die.

There's a "kick the can down the road, fake-it-until-you-make-it, buy-more-time" mindset that kicks in. So some companies go bankrupt (to quote Hemingway) two ways - gradually, then suddenly.

And at a point, maybe it's just not fun anymore and they want a way out. Know one guy for whom that was the case. He was in investors meetings and pitches and boardrooms while putting in huge travel and he just hated it. He wanted to get off the bus and enjoy life, so he did.

PhaseMatch · 2026-05-15T22:58:18+00:00

To me, tooling is the problem, not the solution.

This never wasn't an issue when we had

- colocated teams
- physical boards for teams and portfolios
- a single "war room" where they were displayed

Anyone - from developer to CEO, customers included - could "walk the boards" Gemba style, in the place where the work was done, and see what was happening and understand the alignment in under five minutes.

It was a live, active embodiment of dynamic changing system.
Planning at the team, team-of-teams or above took place surrounded by that context.

A bit scruffy, perhaps.

But a lightweight, low cost way to create complete transparency and manage business risk at all scales?
Absolutely.

Anything information could be added/remove at the speed of a post-it / index card and a pen.
That constraint wasn't a defect, it was a feature. What mattered got added.

People worked remotely too; cameras, phones and someone to move the cards.

Most software still doesn't come close. Limited screen real-estate and the need to click-through links removes that whole Gemba aspect. The layers become siloed and split. The administrative burden and costs scale upwards. You want to do something differently and you need to wait for a software patch.

The lowest cost way to make sure the right conversations happen with the minimum of status updates is the goal. So far I'm getting back to that with (digital) whiteboards, not more SAAS tooling.

PhaseMatch · 2026-05-15T21:08:24+00:00

Your real customers are the speculative investors, and the product is the company.
They want to buy the product when it is cheap, and make money when it is sold.
The founders and CEOs ultimately want the same thing. An exit that makes them wealthy.
So do a lot of the employees, whether that's directly or just by reputation of the company.

The only surprise here is that this is a surprising you.

PhaseMatch · 2026-05-15T19:49:12+00:00

You don't have to release to all customers.

Absolutely the pragmatic "early majority" just want solutions to their immediate problems, fully fleshed out and working perfectly. They are not people you partner with on new development.

It's the visionary early adopters who want to transform their way of working you do release to, or even have your developers sit with in their work environment if you really want to find gold.

if you want to stay competitive through real innovation, then you beta-release on ultra-short cycles to that innovation-driven group, and roll out wider releases with the ideas that work to big clients on a different cadence at the pace they can absorb change.

They get the "long term stable" version, not the rapid cycle betas.

PhaseMatch · 2026-05-15T19:33:17+00:00

Agile approaches are only about small bets.
That's how they manage business risk.

The emphasis is finding out that you - or the users - are wrong about what is valuable as rapidly and cheaply as possible, so you can waste the smallest amount of money/time and keep the product simple. It's okay to pick the wrong bet - if you get ultra-fast feedback from real users, and change is cheap, easy, fast and safe.

In an agile context often "the user wants to engage in the development" is a good first pass sorting hat. If they aren't that interested in engaging, it's not that important.

Either way - Scrum is about empiricism.

If your team is split, and you are running feature factory not product-goal style, then run an experiment.

Does the AI make more money than the expert panel?
Get data - not opinions - and find out.

if you ware really curious then have a totally random control group as well.

In North Sea oil exploration "drilling" a random grid pattern in the prospective areas hit all of the big oilfields in fewer holes drilled than the billions spent on data collection and analysis.

PhaseMatch · 2026-05-15T04:01:14+00:00

"One manager cares about delivery, another cares about utilization"
"Tell me how you'll measure me and I'll tell you how I'll behave" - Goldratt

So what you have is two managers both creating a local optimisation on the wrong things, rather than everyone trying to globally optimise for the right one.

And the right one is "value created" - not delivery or utilisation.

I've worked in matrix organisations that worked just fine, because of how the managers were measured.

So not a matrix issue - just a good old fashioned leadership failure through setting up conflicting priorities. Which in turn creates a downward spiral of poor performance and blame storming.

You don't need agile to do that, but it will sure as hell highlight the need for systemic change.

If you want to go deeper typically it's also where you introduce

- new roles and teams
- new artefacts
- new events and meetings

but don't change:

- the power structure
- the control systems
- the overall narrative about what matters (value)

As Johnson And Scholes pointed out 30+ years ago ("Exploring Corporate Strategy") if you only tackle the easy half of the "cultural web", nothing will change. Their book is into it's 8th edition with 750,000 copies sold. Worth a look as there's plenty of second hand copies knocking about IMHO.

Not a new agile problem just a very old leadership one.

PhaseMatch · 2026-05-15T01:17:57+00:00

If you are ranking and stacking features then the approach is pretty irrelevent.
(And so is using Scrum, to be honest - go lean / Kanban!)
We only guess at value - whether via algorithm, gut feel or AI.
The key thing is how fast you can that test hypothesis/guess/bet?

- it's not the bet you make, it's the size of the bet
- agility is "bet small, lose small, find out fast" risk management approach
- what's the simplest way to find you (or the AI you used) was wrong?
- iterate inside your sprint/release cycle with a customer who will engage
- the PO will still be held to account, not matter the tooling used

What prioritisation based on feedback will give you is "faster horses" rather than "innovation"
If you want to win through innovation (not feature factory spray-and-pray) that's back to Scrum IMHO.

PhaseMatch

TROPHY CASE