11 ms·
What I learned after managing a small team for 2 years
- gumballindie 3y ago"Agile is not always the answer" This ^^ is the sign of a future good manager.
- TylerE 3y agoThe way it's typically applied these days, I'd go much farther. Capital A Agile is often not only not the answer, but the problem.
- abacadaba 3y agoliterally just stop the stupid meetings interrupting every workday other than maybe standup and grooming and then get out of our way and watch productivity improve /rant
- lmm 3y agoStandup, backlog/planning and retrospective are literally the only meetings you're supposed to be doing. I'm always baffled how people manage to do the exact opposite of agile and blame it on agile.
- abacadaba 3y agoI don't blame agile I blame the consultants and charlatans and the execs that listen to them. Also get rid of retro if there's anything to talk about do it in standup.
- lmm 3y agoNah. Standup is for day-to-day current status. It's worth having a regular point where you have a think about how well your process is going over the longer term and if there's anything you want to change. You can always cut it short if everyone's happy with the current state of things.
- abacadaba 3y agoand we're out here having meetings about how to make retro more actionable.. but ya it's really more scrum and associated bs that i have a problem with vs og agile.
- lmm 3y ago> and we're out here having meetings about how to make retro more actionable.. That's something the retro itself should do. First part of the retro should be reviewing the results of the last retro and what's been done about them. (And WTF are you even doing in the retro if you're not coming up with actionable things?) > scrum master or agile guru Lol no, I think those are probably scams. Actually doing agile works, but those positions are probably anticorrelated with actually doing agile.
- lylejantzi3rd 3y ago> Documentation is everything What I learned after managing a small team for 2 years is that documentation is only good if the team can find it, if the team bothers to look for it, and if the team takes the time to read it. I can't tell you how many times I've linked pertinent documentation in Confluence from the Jira task, only to have the developer ignore it. What black magic do you have to cast to get devs to look at the documentation?
- gumballindie 3y ago> What black magic do you have to cast to get devs to look at the documentation? README.md files in each repo, and code level documentation. The readme file can point to useful links, such as diagrams or stuffy documents where needed.
- ozim 3y agoYou don't put everything in README.md for the start - once file gets long enough no one will read it the same as bunch of confluence... Links? Parent poster just mentioned he was putting relevant links in JIRA tickets - to work on a feature dev has to open the ticket anyway but suprise-suprise they were not clicking the links. How on earth README.md links will help in such situation.
- gumballindie 3y agoOh when i read documentation i think stuff relevant to getting things to run, architecture and perhaps a little more of whats relevant. Jira tickets and all can be correlated with a proper branching model. I agree, readme files should be concise.
- stock_toaster 3y ago> What black magic do you have to cast to get devs to look at the documentation? Not use Jira and Confluence? More seriously, I have found that confluence is where documentation goes to die. Something about the tooling, the slowness, poor search, admin tools leading to overzealous compartmentalization, not-quite-good plain text format, awkward gui editing tools, versioning system, distance from the code[1]... something... just makes it not really great at being a repository for keeping documentation up to date, or easily usable. [1]: eg. not using the same tools/editors to modify the documentation as you do the code
- ilrwbwrkhv 3y ago> Agile is not always the answer can be generalised to: Agile is never the answer.
- glonq 3y agoI can think of several facetious questions to which "Agile" is the answer /s But on a serious note, like it or not Agile is sometimes the answer.
- tacker2000 3y agoSo whats the answer?
- datadrivenangel 3y agoKanban with scrumlike characteristics. Or a project plan that gets iteratively more detailed as you get closer to the work.
- dasil003 3y agoIndividual agency granted in proportion to expertise. If the ambitions exceed the teams expertise than no process will save you.
- nikau 3y agoHire smart people. Use common sense. Get rid of bull shitters who regurgitate the latest fad on medium.com without any thought of its appropriateness for your environment.
- glonq 3y agoI've managed small-to-medium teams for a very long time. Agile is very often not the answer, because on a small team you don't have all of the people and roles necessary to do agile "right". I tend to just do Kanban with frequent demos and milestones. I agree on documentation. I try lead by example and document all the important bits to a "hit by a bus" level. Because on a small team losing one person means losing a big chunk of knowledge.
- Scarblac 3y agoTo me a core part of agile is self managing teams. It makes sense that a team manager sees it as not the answer.
- glonq 3y agoMy disdain for agile comes from being a developer more than from being a development manager. I get how and why it sometimes works, but the whole cult of agile is a bit much.
- ipaddr 3y ago"Don't change everything at once" Sometimes one big change is better than constant small changes
- ozim 3y agoAgile is not about sprints or ceremonies that is SCRUM. Sprints don't have to be 2 weeks or more - if stuff changes weekly you do weekly sprints. I just fail to see how one can build anything if priorities change on a daily basis. Most of the features I work on take 2 days at least with 3-5 days most. I can see how one might need to change priorities once a week because you see bunch of stuff built get someone to check it, plan new things that need to be done or adjusted. I am quite experienced but to get meaningful feature worked out it is at least a day of work. I can imagine if someone comes up with text changes, color changes or wants to move buttons around on the interface I could probably spit dozens of these in a day.
- deleted 3y ago[deleted]
- rented_mule 3y ago> I just fail to see how one can build anything if priorities change on a daily basis. I experienced something like this in a startup where I was one of five engineers. We were lucky to have individual offices at the end of a hallway. The CEO would walk down the hall a couple of times a week, stopping in each office, and change priorities on us. He had no idea how disruptive it was and always laughed when we told him. Eventually the CEO saw that we were making very little progress, but attributed it to lack of engineering management rather than priority churn. He was absolutely right, because part of management is managing up. Luckily he hired someone who was great at that. The new manager spent time talking to each of us about our frustrations and then watched everything for a few weeks. He then realized that the priorities were going in circles - every few weeks the CEO would get back to the priorities from a few weeks earlier. So, whenever the CEO changed the priorities, the manager would say "we're on it" and not tell any of us. It took us a while to figure it out, but he'd also stall our releases until the "new" priorities lined up with what we were ready to release. Both productivity and morale sky-rocketed. And the CEO was happier than ever. I worked with the same manager in two other companies in subsequent years - I never felt as productive under anyone else.
- andrei_says_ 3y ago
- jonpurdy 3y agoMVP: minimum viable process I’ve worked for a few orgs as a TPM. If you can get by with a kanban board and weekly sync meetings, and everything else async, do that. If you need more rigor or the team is big enough or developing software that would benefit from Scrum, then go for that. Most importantly, get team input and buy-in. There’s no point in dictating process to teams if they’re not into it.
- nikau 3y agoMVP: maximum possible tech debt. I know the theory about reducing scope, but my experience has been 100% keep the scope and reduce the quality.
- ericksoa 3y agoThe guy seems pretty earnest about this, seems like it is literally his first blog post. It would not shock me in the least if people work in an org where they say they are "going agile", takes them through training where some Scrum Salesman conflates agile with scrum, leading to observations like "agile doesn't deal with change fast enough" Honestly, we need a new word for it at this point.
- azangru 3y ago> But most of all, agile doesn’t fit in the context of this particular project, because the client changes priorities very frequently. The whole point of agile software development was to make it possible to adapt to an environment with frequently changing requirements. The hint is in the name — agile. How can "very frequently changing priorities" be a factor against agile software development is completely beyond me. "Agile" doesn't mean "scrum done badly", if that's what he is implying.
- mdgrech23 3y agoAgile was always about selling training courses, books, certifications and what not. They managed to sell this by telling the business it would let the dev team move faster/need less people/save money. After years people are not finally realizing this sales pitch never came to fruition.
- siva7 3y agoDelivering faster was never the promise of Agile. It also can't turn a shit team into an agile team. But it certainly empowers a solid team to deliver what business needs while moving faster.
- BarryMilo 3y agoAgile is better than nothing, which is what most teams would/did have as an alternative.
- __pache__ 3y agoHuh? Why don't lots of successful open source softwares run on agile, then? Pretty sure having motivated people who find the work kinda fun destroys agile/any other methodology. When people wake up excited to pull down tickets or just get shit done, you're doing business right.
- azangru 3y ago
- theptip 3y ago> However, looking back, I don’t think we needed agile or sprints. The project is not big enough (in scope and size) to justify a system like that. But most of all, agile doesn’t fit in the context of this particular project, because the client changes priorities very frequently. As in, weekly, and sometimes daily. So sprint planning goes out the window every week when new requirements and priorities are discussed Sounds like you needed to be very agile! But maybe not Agile(tm). Honestly Kanban (what they were doing before) is a great fit for this sort of environment. But for a small team maybe you don’t even need that much structure.
- screye 3y agoGenuine question, Do we need Agile, Scrum, Kanban, Waterfall, etc. ? It's glorified to-do lists with an opinionated cadence on how often features get deployed. Do we really need an entire discipline to communicate those simple things. How flexible are we with requirements ? How many stages are in the to-do list ? How many hierarchies are in the todo list? How often do we features to be deployed ? What more do you need to know ? Takes 1 long meeting establish a well-communicated bespoke development cycle for each team. Do we really need a phrase for that ? My experience tells me that the system gets sub-optimally molded to suit the implicit development style of the team whether you like it or not.
- __pache__ 3y agoNo, we don't need all this nonsense (on small teams) I hate all the meetings, which we can "feel" don't make sense. When we all "feel" a meeting makes sense, we naturally hop in. Totally different vibes.
- lmm 3y ago> It's glorified to-do lists with an opinionated cadence on how often features get deployed. Do we really need an entire discipline to communicate those simple things. Apparently we do, since we still get people who want estimates months in advance (and then want to punish you if those estimates were wrong), who want to commit to a plan and then follow it and then change it without changing the deadlines, .... > My experience tells me that the system gets sub-optimally molded to suit the implicit development style of the team whether you like it or not. Isn't that precisely the proof that the development processes haven't been communicated clearly enough and got enough buy-in/consensus?
- nikau 3y ago> since we still get people who want estimates months in advance Its almost like the real world has deadlines and interactions with 3rd parties who need to schedule things too.
- deleted 3y ago[deleted]
- gerdesj 3y agoA delightful post and there is a very decent message in amongst the happy puppy grows up stuff: "If I had to do it all again, I would have immediately sat down with each team member individually to hear their thoughts about:" Do that and then do it again collectively and do it repeatedly. People need to be needed. People need to be valued. People who feel needed and valued tend to perform best. You don't have to be best mates or even like each other - that's tricky but do able.
- pyb 3y agoAgile detractors like myself may find this amusing : "agile doesn’t fit in the context of this particular project, because the client changes priorities very frequently."
- deterministic 3y agoI have successfully managed 15 person teams using a simple to do list sorted in priority order. It’s simple. It works.