2,243 karma · joined April 25, 2012
That doesn't take anything away from the knowledge work that happens when you develop software, but the code itself is not the art. The solution is the art.
Perhaps like most popular art, it's more about the story behind it.
Rather than treating these as fixed teams, we treated them as workstreams that people rotated between every sprint (every two weeks).
It worked for about 3 months, until it didn't - by then we had grown enough to organising the teams around the business capabilities or domains instead.
I don't get the use of midwit meme here. Either you're implying that you're preaching the the choir, in which case it's just an echo chamber, or you're calling your audience idiots. Neither outcome is great.
There's always a balance. Being overly orthodox about methodology is suboptimal, yet equally, having no guard rails when people need them is equally as bad. Going around expecting everyone to work exactly how you work is not the reality and tends to lead you down one path.
Today, for many businesses accounts is still the main driver behind software, and also the budget.
Which means, prototyping in this way, but at the point it is actually delivering value, stabilise.
Of course, it’s never as simple as that, but there’s certainly a place for this technique.
In a highly interrupted team, sprints don't work. Try lean/Kanban.
You've not mentioned retrospectives, which are an important part of improving your processes, without that how can you make improvements?
There's nothing in agile that talks about deadlines, it's about commitment.
I imagine they've underestimated what it takes to operate as a domain registrar, and presumably there's too much politics and conflict of interest in that space.
Most of the time it’s likely to average just under a 5, so you round up, as most work will fit within a week, which is the underlying “effort” you’re getting from velocity.
For a team of seasoned developers you might as well make everything a one and go kanban.