| After 14 years of trying and helping teams experiment, repeating what other have said, here is what we’re doing nowadays: - don’t mix up Agile with Scrum... - see Agile as aspirational (aka read an try very hard to go back to the manifesto to clear the clutter) - see Scrum and XP as tools - prefer XP to Scrum : yes, it’s better to have good software in the middle of a shitty process than a good process around a shitty software. believe me, good software, even in nightmarish organization can bring joy. don’t be the opposite. :-) - be concerned about the internal well oiling of the team first and the the product: same than with the process, a good team can course-correct a bad product decision or a user backslash (to a point), the opposite is way harder...imaging trying to keep your users telling them your product is superb, it’s just that the software works half of the time... For the’code part’ XP if you can/know, or just start with automation (basic ci/cd or cr, tests).
Then raise collaboration by making it easier to ‘code together’, agree on ‘code expectations’ and communications expectations whatever that means for your lot.
THEN everybody should approach their ‘quality standard threshold’. The way is just up from there: code coverage, TDD/BDD, code review, IaC, you’re already pretty ‘software agile’ at that point, but like a circus artist, reach for always more agile Next the ‘product part’: That’s where most Scrum consultant will hammer you with the dailys, the demos, the ceremonies and all.
Back to the manifesto.
Learn what your people like, what and when it makes them productive. Make it weird, unwieldy but a perfect-fit for you all. If a consultant looked at it, it should say ‘oh, ok, that’s a weird way to do it, but I guess it could work’. To put my money where my mouth is, here is what we do
(but it’s full of our remote, bilingual, socially multi-diverse quirks). We start and end at a demo to our C-level and business ‘patron’. Just after the ‘last one’, we pick what we will try to demo next time.
We talk about the value of it.
To whom in our demo audience/user it should evoke excitement. What would be ‘minimum’ otherwise we dont show up. What would be ‘nice’ and what would be mind-blowing.
We all agree what a user should see. We settle on it for the next weeks (yes, no prefixed date).
In general there’s one or two ‘big things’ that would constitute ‘the meat’, we create one/two sufficiently descriptive stories with personas that should match what we discussed for the demo and Condition of Success in JIRA and put it as In Progress. Everything else, except production issues, is considered unimportant and optional. If one of us has time during build or waiting for a review, we tackle the ‘little things’. The PO/Business DoppleGanger goes get what we need to do all that (wireframe, design, translation, legal wording, marketing spiel,...). He/She works directly with the devs that need it.
We meet every Thu and Fri for 5/10 min (usualy, max 30) entirely to make sure sub-groups or individuals are not missing on what other will be doing and profit from it.
We talk about what we’re working on next not the past (the past is done, stop wasting time talking about it!!! :-)). No task, no story bs, no past ‘blocker’ discussion lingering. If people want to track their stuff in github issues or JIRA, they do it on their own. But they better make sure it’s tidy and up to date cause we do not accept messy backlogs. In between those ‘bi-weeklies’ if someone in the team need to discuss anything or are blocked, they shout on Slack and wait. If it’s an emergency, they send a mean Giphy. If they really need someone, they DM a lead. and so on. People own what/how/when they do 200% up until we approach the end of the 2 week threshold. Then it’s about all that we achieved. The big question is asked ‘are we ready to demo’? If a majority don’t think we have enough to show, we wait another week and ask the same question. Then week 4, same. At that point we need to have a freaking good reason not to be showing something after 4 weeks. Even if it’s minimal. Even if it’s a bunch of HTTP calls and some JSON. And we cycle. In summary: - 2 meeting of max 30 min (you can drop of after that) - lots of behind the scene ‘ad-hoc’ interactions per need (that respect a ‘rule of engagement for collaboration’ the team agreed on, btw) - 1 demo, tailor-made to the actual delivered value by the team (not the dreamt one) every 2, 3 or 4 weeks Practice wise: IaC all the way (tks Pulumi and Google Cloud team), CI/CD (with real automated delivery not CR), code-review using PR and on-demand env, fully diamond-shaped code coverage, dependabots and automated CodeSec audits, conventional commits with semantic versioning, and we’re just starting. -> No planning (except the 40 min discussing the next demo just after the current one). -> No poker estimate. In fact no estimates. -> No backlog burn downs and cycle time and resolution time... -> No WIP (technically, yes, this is Scrumban-ish with a WIP of 2...). We do one quarterly product vision discussion with everybody that feeds team
growth and high level
product roadmap (no precise estimates, in terms of Q or 2 month span). That, I believe, can be called agile :-) |