mhale

This does not appear to be a total outage. I cannot reach any of our sites, and Pingdom also reports we are down, however, I can see normal looking traffic reaching our servers (via heroku logs --tail). In addition, members of our team are reporting via Slack that some can reach our Heroku-hosted sites, others cannot. It seems to be ISP-related. Two people within 1 block of each other on different ISPs see different results.

We proxy some services through Cloudflare to gain IPv6 support, and all of those are down, which suggests the Cloudflare -> Heroku network route is broken.

Heroku apps are down, but API access is available.

Might be a good time to run: heroku pg:backups:download

It's not about tech point scoring, it's about quickly solving a problem. Specifically how can my customers on IPv6-only networks reach my service hosted on Heroku (which does not support IPv6)? Cloudflare is a practical and relatively easy solution to that problem.

Yeah, I struggle with this. Often when I see someone my brain doesn't present single name match, more often I have a list of potential matches in my head. e.g. "Scott or Rob" -- so I'm forced to just go with one, or avoid saying any name at all. I've gone for it and botched a name before and it was truly embarrassing. Often given a few seconds I can recall with certainty. It's the one-the-spot instant name recall that is difficult for me.

I'm pretty bad at remembering names, but my wife and I have worked out a system. If we're in a social setting together and I start to introduce her "have you met my wife..." she will jump in and introduce herself directly to the other person "hi, I'm Colleen...", which prompts the other person to directly introduce themselves to her (and thus taking me off the hook). As a result, if someone is introducing me to someone else, I tend to do the same thing -- hijack the introduction and introduce myself directly -- just in the case the person making the introduction needs an assist. Of course, if they've already greeted the other person by name, then no need.

I worked on a project that required some pretty standard line charts, but with the addition of an overlaid set of horizontal "benchmark" lines -- and some callouts. After struggling (and failing) to get what we wanted out of two different off-the-shelf graphing libraries (one of which was built on top of D3), we finally bit the bullet and just built the charts we wanted in D3 "from scratch". Once I wrapped my head around the model, it was such a pleasant experience. D3 is soooo nice and well thought out. You mayneed to level up in SVG, but it is so freeing to be able to bind data and display it basically any way you want. In hindsight, I wish we started with D3 from the beginning and I would not hesitate to pick it up for even simple charts again. It really is worth climbing the learning curve, which isn't as big and scary as it appears at first sight.

Sounds like an issue for the board of directors. Do you have a board of directors? If so, I suggest reaching out directly to board members one-on-one to raise these issues with them.

The most important agile practice, imho, is far and away the Retrospective. A good retrospective process will fix all other problems.

In the post, you sort of dismiss it out of hand because it is supposed to be a discussion limited to scrum, but that is an arbitrary and self-imposed restriction. You are doing it wrong. Remove that restriction and the doors will open up.

The retrospective is about creating time for the team to review what works and what doesn't about the software development process in general (no need to limit to scrum).

I've seen retrospective discussions veer into company culture, the need for faster hardware, testing processes, etc. Anything related to making the software, the software development process, or the team better should be on the table.

A good retrospective enables the team to use its sprints as experiments to try different things, to evolve the practices to better fit the needs of the team and organization. If stand-ups aren't working, go a sprint without them, or doing them differently -- whatever change would address the weakness identified by the team -- then in the next retrospective reflect on whether it actually improved things. Rinse and repeat. Done properly, a good retrospective will enable your team to evolve and get better and better with every sprint.

Points can be frustratingly fuzzy, but they serve a valuable purpose. They give a measure of team productivity (e.g. velocity), even if imperfect. Yes points can be gamed, but a team should learn quickly that gaming only serves to fool themselves. Because of they can be gamed, I'm not a fan of using points as an externally visible "vanity metric". They should only be used or shared within the team. They should not show up in performance reviews or presentations to management. But points can be very useful as an internal metric for the team to measure whether or not tweaks to the process made a positive impact. You need some way to objectively measure the success or failure of your process experiments.

Of course, any metrics used are themselves certainly deserving of scrutiny and fine-tuning, as poor metrics lead to poor decisions. To me the benefit of points (or t-shirt size estimates) over something like hours is that in software development, hour-precision estimates give a false sense of accuracy. It requires more effort to provide more precise estimates, yet they won't be any more accurate (given the inherent non-repetitive nature of software development). Thus, the use of a coarse-grained measure like points serves to re-enforce the notion that the estimate are inherently imprecise and that we don't want to waste effort on greater precision estimates.

All that said, whether or not to use points or any measure of team productivity at all is a team decision. If the measure isn't serving the goal of improving the software and the software dev process, then change it or get rid of it. That's the beauty of the retrospective -- it explicitly encourages this sort of process-hacking and fine-tuning.

Embrace the Retrospective!