Agile. and I don’t mean Corporate Agile, I mean true, by the books, real Agile. Team driven from the get go: Developers, Product Owner, Scrummaster. That’s it.
Agile has been bastardized by corporations for so long that developers think it’s not for them. Agile was built to be developer-driven, the dev team should be making all decisions and setting their own pace. The developers should decide
What points mean
How many points stories take
If a story is fleshed out enough
How long sprints should be
How they want to run their process
Corporations have turned this around and ripped control over the teams from themselves to impose insane company wide rules. Things like points being rigid tied to time things (points should be a “gut check” feeling on how complicated an item is, Not based on time, i.e. “this is a 1 point story, it’s similar to a config change and we call that a point”. This means that jr developer or senior developer doesn’t matter, it’s always 1 point), rules around when meetings should be (dev team should decide when standups should happen), the length of sprints (some teams like 1 week, some teams like 1 month, agile doesn’t care as long as they are producing), and just so many things.
Agile is supposed to be “Let developers make a process that works for them, business should be able to adjust”. Usually if I join a company and their scrum process is dictated from business it means that the business side/project managers were too lazy to translate the dev team’s structure into business terms (something that any competent scrummaster would be able to do)
Anyway, thanks for coming to my Ted Talk
-A very burnt out scrummaster who has been told by too many MBAs how Agile works.
I would even argue that points, stories and sprints are not things you need. If you go kanban, you don’t need sprints. You still need to be producing and you probably want to get a feel for complexity so you can prioritize, but that can be done without points.
Stories are also very scrum specific and you can turn them into whatever format you want. I usually still call them stories, but they’re basically just a little card that describes the context (why do want something) and the deliverables (what will be implemented to meet that want).
which I’ll fire back and say should all be team decisions. Usually with my teams I try to persuade them to go sprints at first while they’re getting to know each other, but Kanban is always a possibility. Thing with Kanban is that you need a lot of trust within the team and a lot of honesty, things like “This story is really really stuck and idk what I’m doing wrong” vs letting it sit there holding up the WIP count.
Oh, it should absolutely be the team’s decision and you’re also totally right that Kanban requires a more mature team. People indeed need to be able to recognise and ask for help when they’re stuck (which means being vulnerable, but also simply being able to formulate the right questions). People also need to be able to give feedback to their team members when they feel or see that someone is struggling or not delivering enough.
To facilitate I always have some form of retrospective in my teams, even when doing Kanban. Sometimes only once every other month, sometimes every two weeks. Highly depends on the maturity of the team and customer.
It’s extremely freeing realizing that coding in a business environment can be fun, it doesn’t have to be torturous. The big companies just love micromanaging though.
As long as you’re following the manifesto and the principles, you’re good. You’ll notice this doesn’t talk about scrum or kanban or safe or whatever, those are processes that try (sorta) to follow these. But if you’re ever in a situation where somebody says “this is the process we’re supposed to do” hit them with the manifesto.
Agile. and I don’t mean Corporate Agile, I mean true, by the books, real Agile. Team driven from the get go: Developers, Product Owner, Scrummaster. That’s it.
Agile has been bastardized by corporations for so long that developers think it’s not for them. Agile was built to be developer-driven, the dev team should be making all decisions and setting their own pace. The developers should decide
Corporations have turned this around and ripped control over the teams from themselves to impose insane company wide rules. Things like points being rigid tied to time things (points should be a “gut check” feeling on how complicated an item is, Not based on time, i.e. “this is a 1 point story, it’s similar to a config change and we call that a point”. This means that jr developer or senior developer doesn’t matter, it’s always 1 point), rules around when meetings should be (dev team should decide when standups should happen), the length of sprints (some teams like 1 week, some teams like 1 month, agile doesn’t care as long as they are producing), and just so many things.
Agile is supposed to be “Let developers make a process that works for them, business should be able to adjust”. Usually if I join a company and their scrum process is dictated from business it means that the business side/project managers were too lazy to translate the dev team’s structure into business terms (something that any competent scrummaster would be able to do)
Anyway, thanks for coming to my Ted Talk -A very burnt out scrummaster who has been told by too many MBAs how Agile works.
I would even argue that points, stories and sprints are not things you need. If you go kanban, you don’t need sprints. You still need to be producing and you probably want to get a feel for complexity so you can prioritize, but that can be done without points.
Stories are also very scrum specific and you can turn them into whatever format you want. I usually still call them stories, but they’re basically just a little card that describes the context (why do want something) and the deliverables (what will be implemented to meet that want).
which I’ll fire back and say should all be team decisions. Usually with my teams I try to persuade them to go sprints at first while they’re getting to know each other, but Kanban is always a possibility. Thing with Kanban is that you need a lot of trust within the team and a lot of honesty, things like “This story is really really stuck and idk what I’m doing wrong” vs letting it sit there holding up the WIP count.
Oh, it should absolutely be the team’s decision and you’re also totally right that Kanban requires a more mature team. People indeed need to be able to recognise and ask for help when they’re stuck (which means being vulnerable, but also simply being able to formulate the right questions). People also need to be able to give feedback to their team members when they feel or see that someone is struggling or not delivering enough.
To facilitate I always have some form of retrospective in my teams, even when doing Kanban. Sometimes only once every other month, sometimes every two weeks. Highly depends on the maturity of the team and customer.
I am, for the first time, in an actual agile environment, and it’s amazing. I love our product manager.
It’s extremely freeing realizing that coding in a business environment can be fun, it doesn’t have to be torturous. The big companies just love micromanaging though.
The book in “by the book”; Any book to recommend?
As long as you’re following the manifesto and the principles, you’re good. You’ll notice this doesn’t talk about scrum or kanban or safe or whatever, those are processes that try (sorta) to follow these. But if you’re ever in a situation where somebody says “this is the process we’re supposed to do” hit them with the manifesto.
It’s impressive how few people have read the 4 (four) lines of agile manifesto, especially buisiness people.