Archives - Products Are Hard

Beyond Lean and Agile

August 28, 2013 By Abie Hadjitarkhani

Rose Powell of Australia’s StartupSmart interviews us on situating Agile and Lean in a holistic product practice.

Beyond lean and agile: Finding a more holistic approach to start-up creation

You need to step right out of it and remember no one’s goal is to use your product. They want to get something done. Does your product do that in the best, most efficient way possible?

Dig the conversation? Fancy being in Melbourne, Victoria on October 30? Join us for the Products Are Hard conference, Australian edition.

I’ve always been uncomfortable with the term sprint. It’s a short word, easy to say and quick to type, but the connotations can be misleading, especially for people new to Scrum. I used to run track in high school, and I have a pretty vivid body memory of what it felt like to sprint – an all-out blast of energy expenditure that left me panting, heaving, and, sometimes, if I’d pushed hard enough, even nauseated. I was no Usain Bolt, but I wasn’t a slug either. I was a regular person, reasonably able to run pretty well. It left me in no condition to do anything but sit there recuperating until my muscles and lungs stopped screaming and returned to functioning normally.

You can’t sprint your ass off, pause for a minute, and then do it all over again. It’s not sustainable. And yet one of the most important benefits of the Scrum framework is that it provides a sustainable rhythm for work. It’s meant to be the opposite of a death march or a self-destructive series of Jolt-fueled all-nighters followed by days of hibernation and recovery.

There’s always the argument that after enough use, the word itself becomes a signifier for the concept and its connotations become less relevant. Who, after all, thinks about chitinous little bugs when talking about John, Paul, George, and Ringo? But words do matter, otherwise we’d refer to everything with algebraic letters, symbols, or glyphs. So, no, I’m not proposing that we start referring to sprints with Σ (even though that would be awfully cool), but language being what it is, the other commonly used terms are each fraught in their own ways. I tried using iteration for a while, but Nathan found that made people think about dozens of tiny, obsessive refinements towards a specific ideal. Sprints are about getting shit done and perfect being the enemy of good, most definitely not about obsessiveness or idealism. Timebox, another common-ish term, feels cold, bureaucratic, and constricting. So, in the spirit of Scrum, we continue to try out different words, getting a sense of how well they do or don’t work, and we iterate our way forward. We may never have the definitive word, there certainly isn’t a perfect one, but in the meantime we’ll keep talking, training, coaching, and working.

UPDATE: Sasha Magee offered some interesting proposals from the sport of cycling:

@abie cycling calls the “hard but not so hard you can’t go again” thing “intervals”. Or, in a race, “attacks”. Latter works better for Scrum

— sasha magee (@sashax) August 22, 2013

G+ identity follies

July 23, 2013 By Abie Hadjitarkhani

Google wants real identities on G+. No pseudonyms. (After enduring enough protest, they relented for those with established pseudonymous public personae.) And yet, Google also gently but persistently harasses you to setup a G+ identity for every Google account you have. At the moment I have two personal Gmail accounts and three Google Apps work accounts. Google keeps insisting that I make a G+ profile for each one of those accounts, either by pestering me upon login or by disabling key features of applications like Hangouts for accounts without a G+ profile. I now have five G+ identities to manage. I can laboriously recreate my “circles” on each one and flesh each of them out, figure out some way to syndicate one of them to the other four, or simply ignore most of them, leaving them to molder as dusty ghost profiles. It’s hard to see how this is good for the health and vitality of G+ as a community or social network except to artificially juice the number of users.

Text trumps video for remote teams

June 7, 2013 By Nathan Dintenfass

Over the last few years we’ve done a fair amount of work with remote development teams. One of our current clients is going through a company-wide transition from waterfall to agile, and they use remote contractors extensively. A primary goal of the transition is to make better use of the full talents of their engineering team, so good communication is essential.

When working with remote teams, it’s tempting to try to replicate the experience of an in-person meeting. Google Hangouts make the features of much more expensive teleconferencing products available to a wider audience, and increasingly we see companies set up their conference rooms with large monitors hooked up to a simple webcam to use Hangouts or Skype.

The aforementioned client uses Google Hangouts as a matter of course for all interaction with engineers, putting heavy emphasis on video conferencing in an attempt to make the remote developers feel more a part of what’s going on. In sharp contrast, a different client holds their morning stand-up meetings exclusively on IRC (even when they’re all in the same building) – old-school, text-only group chat.

Text works better in most cases.

The simple truth is this: giving a meeting your full attention is hard enough, but giving a meeting your full attention when you’re attending remotely is impossible. This is particularly true when you’re a remote software engineer and the topic is something other than the particular bit of code you’re working on. Remote developers are not going to give their full attention for the entire duration of a meeting. It’s not the way our brains work.

Three more concrete reasons we prefer text-based remote discussions:

A text-based conversation is much more forgiving of momentary distractions. If I zone out of the discussion for a minute while I answer an email I can quickly catch back up by reading the transcript.
A text-based conversation ensures everyone gets their ideas in. In a voice/video conference it can be difficult to know when there’s an appropriate pause in the conversation to interject. When an engineer in Bulgaria is trying to provide input to a conversation happening in a room in Mountain View, they need a way to interject without having to force their way in.
A text-based conversation can be reviewed later. If someone misses a meeting or arrives late, or if you need to refer back to the discussion after the fact, a text-based conversation is there waiting for you. This also frees everyone from needing to scribble notes furiously while the meeting is in progress

Video and voice have their place. One-on-one or small group chats can benefit from the immediacy of video. If the remote party is leading the conversation or presenting it can also be beneficial for everyone to see that person. If people are not expected to participate and just listen it can be nice to be able to hear and/or see the person presenting rather than needing to read. Text works well when a group of people all need to participate.

Google Hangouts can serve both purposes as it has text-based chat is built right in. IRC is the classic text-based chat, though modern products like Campfire, HipChat, and other online collaboration tools are more manageable if you don’t already have IRC set up (built in logging, image rendering, file uploads, etc. are some obvious features IRC doesn’t offer easily).

PAH13 wrap-up

April 9, 2013 By Nathan Dintenfass

PAH13 is in the books. By all measures it was a success. Thanks to the over 200 people (30% more than PAH12) who made it a great day. Early feedback has been overwhelmingly positive. Particularly encouraging was how many teams came together, and we had multiple people say they wish they’d brought the people they work with every day. Next year we will put more even more focus on making it valuable for teams to attend.

After PAH12 we wrote a postmortem on our first attempt, and this year we definitely felt like we’d made it up the learning curve quite a ways. It helped that we did it at the same venue, though we filled the room, so we’ll need to decide if PAH14 can fit in that space.

Below are links to the slides from the speakers along with any supplemental links the speakers provided us. Also, Carolyn Wales has agreed to let us post her personal notes from each talk (along with delightful little sketches of each speaker).

Thanks again to our lead sponsor, GitHub, along with Klout, Zendesk, Pivotal Labs, and Chirrpy.

We will update this post if we receive additional supplemental materials and/or when we get audio/video of the talks.

If you have any feedback we’d love to hear it. Get in touch!

Be sure to follow us on Twitter (@productsarehard) for updates on future PAH events.