I tried to hang with this but got lost about halfway: https://medium.com/airbnb-engineerin...o-aa4ec92d69e2

Interesting take down of Jira: https://techcrunch.com/2018/12/09/ji...n-antipattern/

The main point, that you can't see the forest for all the trees I agree with, some of the rest is him complaining about how people use the tool and longing for big up front planning which isn't very agile.

(For my purposes) I have yet to see anything I could accomplish with Jira that I can?t accomplish with github tools. It?s a little more refined, and if i had a larger project i?d probably try to move over, but to me it looked anti-productive. Pure noob/layman?s perspective, obviously

This is all basically a complaint with agile imo. Focusing on the details rather than the big picture is a feature of agile, not a bug. I'm glad I don't have to look at all that crap my project manager does. Just show me the tickets my team has to work on so I can refine and organize them. I can still focus on the UX and architecture big picture as needed, w/o getting bogged down in the project management crap.

It's true that Agile doesn't handle project-wide/cross-sprint platform dependencies well. We used to keep those in a separate project. You just have to give up on that stuff perfectly fitting the model, and be happy it's being tracked and detailed somewhere so everyone is on the same page.

As far as pressure to mark tickets finished - there's a scene in Silicon Valley where Richard converts the devs to agile and gives them a bunch of tasks on post-it notes. Suddenly they're competing with each other to knock all the post-it notes off their plates. It's a joke - but there's some truth to it imo. It taps into a basic human desire to mark your **** finished, slide it over on the kanban board and onto someone else's plate. You start to feel like you have momentum going and get more involved - vs. waterfall where you have this giant list of **** and don't get any pats on the back when you cross out one line on your to do list.

I feel like maybe the author is on a team of devs trying to work Jira on their own w/o a project manager. I don't know what that would be like - but I have a feeling it would suck.

Is there a reason why you don't want to test in the production environment? Integration test could end by deleting the user to ensure the database is clean.

So one of the major issues that came up was lack of communication on all fronts, especially between product and engineering. They pointed to a lack of product manager being a huge issue, but even intra-department communication is pretty god awful. Not only do people not communicate they're completely unwilling to do even the most basic stuff (like answering emails, meeting attendance, responding to github comments, etc.). Yet - they all complain about lack of communication, privately.

So I drafted up a simple 4 page communication plan that outlined what I thought we should do, and especially what would make my job easier. Made a table with various forms of communications, how often they should happen, what medium, who should attend, who owns the communication, etc. Came up with about 8 different kinds I'd consider critical.

My boss loved it and the CEO has yet to see it but I plan on having a company wide meeting to present it. The document is nothing ground breaking but I also threw in quarterly informal performance reviews for my boss to conduct, because he doesn't do those and I think it'd make his job a little easier. He was on board with that.

I'm worried it won't be adopted. So idk what to do about that. I really stressed that everyone needs to be on board. I've been trying to "lead by example" the last few months but I just end up annoying people. I'm having a hard time selling these ideas to my team - a few think that communicating vital info is just an unnecessary annoyance. But I have a few new gung-ho members on my team that I think could spark some energy in the rest.

I can't stress how bad the communication problem is, it's completely demoralizing. Throwing together something as simple as a regular 5 min standup meeting used to be really hard to do, but I finally got us doing that 3x weekly. And we're FINALLY using slack and everyone's on board with it, I suggested that 6 months ago but it got overriden. But now we have a remote hire so we use it.

So....another bloggy post

I got the new machine (virtual I suppose) running on linode, running the flask api, and the react-native app/server running on my desktop/ and then my phone app or whatever you get from Expo picture on the QR code...getting **** from the flask-api.

Hallelujah

lol my document i drafted in literally an hour and a half was a smash hit. I'm gonna meet with all the big wigs this week to discuss it more. Jesus christ, this place is leadership starved. I should just go with it and see where it takes me.

Yeah dude - you're an up and comer!

Well for a while we're not gonna be sure we don't crash production when we do stuff. Maybe after a while we get the confidence to test in prod.

But yeah the test will definitely clean up after itself.

You seriously needed to write up a document telling ppl to respond to email?

I mean, kind of - but the company has been doing things very informally and disorganized for a while and it?s worked because they didnt have a lot of things going on. But now the business is growing, channels of communication tend to get a little funky, critical people are routinely not notified of changes that can affect deliverables, there?s a really bad noise to signal ratio in a lot of what we do as well. Every PM book i?ve read mentions drafting a communication plan, so I figured it?d be a good place to start.

What I really want to do is change the culture a tad and introduce a basic process, there?s a ton of resistance to being process driven but even a basic one could resolve the bulk of our issues.

We just lost our best guy because of this, so I think they are willing to try more drastic change.

Another thing I insisted on is being a key part of projects I?ve been left out of. The biggest gripe was we had a major demo to deliver to a HUGE company that was interested in our product, and it was supposed to be done in a week. It?s been two months and it?s not close. I told them I should have been brought in on this and could have helped streamline things - so now the next big demo we have coming i?m taking ownership of. I?d like to have a system in place so my life?s a little easier.

Email as a way of communicating any kind of project information is a disaster. Might as well be a phone conversation. Any kind of rolling, recorded comment stream - like a github issue - which everyone has visibility to - is much much better.

I always want one central hub for all information - then that at worst links off to other locations. My whole goal in life is to give devs no excuses for not reading the spec, design doc, README or whatever. They still won't a lot of the time - but it makes my life easier to just point them to one place. I like to be able to say "If you can remember devdocs.ourcompany.com - you can find anything. And if it's not there, please add it or at least add a link."

Also keep that stuff to a minimum and accept it will be out of date 6 months into the project. But it's still very useful in the beginning. README >>> other docs.

I noticed our prototyper had notes for himself in his PDF tool that weren't in the insight prototype. I told him to use those as the first page for each flow - so we're all on the same page. It's soooooo much better now. Just little stuff like that makes a big difference.

The holy grail is living documentation like swagger - assuming you're generating something like API Gateway off of it, so it can't get out of date. Otherwise out of date swagger is worse than no swagger. But again, still very useful in the beginning.

Yes this is a good idea. What do you use for a central location? We occasionally use google docs but our account is huge and it?s hard to find things.

I document things in github wiki?s, github projects, and README?s - but the thing is NO ONE refers to them except me.

Yeah just dumping everything in Google docs or Box and expecting devs to navigate isn't really scalable.

In the past we had a giant dashboard that showed running microservices but also had a docs section. It was a whole website, I think based on open source Honeycomb.

I've also used a readme of the central lib repo that all apps used.

Right now we don't actually have one as we're really just prototyping. But I plan to create some kind of static website dashboard thingy and host it on S3.

In order for these things to work really well you need a critical mass of people with some meaningful combination of useful information, reputation, and authority to actually drive usage and adoption.

Nobody is going to change how they work because of a 4-page document (I'm not saying the document is useless), but they'll change if they find value in doing something and the barrier to not doing it becomes higher than the barrier to doing it.

Maybe you could do blue/green deployment. Deploy a new prod setup while keeping the old one there, test the new one, after it passes tests swap everything to use that and tear down the old one.

There's definitely a sweet spot where if you over-document, or if a dev sees a massive wall of stuff, they just tune out. So a README with a quick cookbook and a brief summary of what the repo does is less intimidating than a wiki and valuable to the dev.

The whole goal is you want everyone participating. READMEs are a lot less scary to get started in. You also want a clearly defined benefit to pull devs in.

Then you can link off the the hairier stuff that no one ever reads but it was very useful to you to write at least - and may come in handy to cover your ass some day.

Yeah we're doing that with our wordpress sites hosted on Elastic Beanstalk. With lambda the whole idea of a new environment is just a concept. So it gets weirder. Canary deployment seems popular.

You?re right and this is the problem i still havent solved.

It takes time. Just start with basic stuff like steering people toward persistent comment streams where everyone has visibility to the conversation instead of piecemeal email conversations that get lost.

JIRA tickets are kind of handy for this

VBulletin would be good.