I would like to argue for the psychological safety that Google found in project Archimedes. As a manager (of any group) one of the most important things to bring is to genuinely care for your people. Also spend time on making a culture where colleagues care for each other.
At the same time, it is important to be willing to take the difficult talks and decisions early on. If you have a bully or somebody tearing down your team, take action. This also goes for interactions with the rest of the company. The task of the group is to build the best product/service/whatever for the company, and anyone aiding in that should be welcomed. Anyone hindering it needs to be stopped, regardless if they are part of the team or belong somewhere else in the company.
Finally, make sure decisions, targets etc. are there because they are good, not because of politics or ego. It may take a bit more time early on, but getting everybody on the same page with respect to how and why you (as a team) want to do particular things always pays off.
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.
I am, for the first time, in an actual agile environment, and it’s amazing. I love our product manager.
Don’t treat existing code/design/archtecture is sacred until it’s backed up by static analysis proving it is bug-free.
