Amazon did a great job with that technique and we were inspired a lot by that. Of course companies/startups do less "press-releases" these days, so we adopted it to blogging.
The content of published articles does help not only with team focus, but also is a natural "deliverable" definition for UI-less products such as SDK. Blog post simply cannot be published unless code is in the Github repo, tutorials and sample apps are there as well as illustrations and narration communicating new features.
Tanuj from Estimote business team here. It's also super useful for my efforts. Makes it so much easier to communicate to customers what we're working on, and there's also the intangible benefit of impressing potential customers with how fast and how much we ship -- e.g., https://twitter.com/stevecheney/status/598905085826043905
(blog author here) Thanks for adding the link. Absolutely - it's one of the inspirations for us using this approach. I'd also add Gojko Adzic's Impact Mapping (http://www.impactmapping.org/) as a further source of ideas that was in the back of my mind when tweaking and adapting Blog Post Driven Development with our team.
Perhaps one of the things I should have stressed more is what good fun it is to have robust debate about why our work matters! Planning SDK work (even refactoring / housekeeping) doesn't have to be dull.
I worked at Amazon at the time that blog post was written and this was not a part of the methodology. While it's true they released press releases with BS. EG: The "drone delivery" is an example (no way they are working on that, they know it can't work, they're not dumb, but it does make Amazon seem like a tech company, rather than like Walmart (which is what it's more like.) )
This blog post is an example the BS PR that Amazon does. IT's frankly dishonest self aggrandizement.
Thanks! I sometimes can't see through the B.S., and need to be reminded. In the end, it's about making money--moving goods to consumers. I'll keep an eye out for MCRed. I like the way you think!
It's the best way of setting up a clear goal. At my current job for a new project we only had marketing send over specs to some UX/UI designers and we're going to get the prototype UI sent to the devs for feedback. No idea what the exact goal of this new project is other than to keep up with the competition or to make existing corporate/enterprise users happy. Not the most ideal situation.
I think writing a mission statement or press release before development would sink a lot of projects before they began and save millions.
As a dev-oriented company our SDK team used to ship tons of new code into our Github repos. We realized that our SDK is much harder to productize and define an explicit "deliverable".
Thus past few months we have applied "Blog post driven development" where the aim of the sprint was to build, test, document and communicate SDK changes in a form of a blog post.
This technique is working for us really well, so John who is driving that team as a Project Leader decided to share the details with the HN community. We hope you will enjoy it and feel free to comment.
---
Here is also a snapshot of our recent blog posts as as a proof shipping code with posts is working really well:
- 5/15 - OAuth support for easier integration of Estimote Cloud into your services
- 5/06 - Hugely improved Indoor Location SDK (4-meter accuracy)
- 5/04 - Updated Android SDK
- 4/23 - Improved beacon real-world analytics (new SDK + API)
- 4/21 - Estimote Cloud updates (tag beacons with metadata + GPS ___location)
- 4/15 - Conditional beacon broadcasting (for power saving & easier prototyping)
- 3/24 - Fleet Management API
- 3/18 - New SDK and firmware
- 3/13 - C# and JavaScript support
- 3/04 - Support for Apple Watch
- 2/24 - Infrastructure Sharing (open beacons to 3rd party apps/brands)
- 2/13 - Trigger Engine
Is this why I'm still waiting for my estimote stickers? I'm not sure I would ever build anything user facing with your stuff it's just not a useful platform if you can't reliably get the product.
Edit: It's honest feedback, the down vote is unwarranted.
Wojtek from Estimote here. Thanks for sharing your thoughts and sorry for the delay with stickers: it took us longer than expected to reach mass production. It was a lot of work (and admittedly more time than initially assumed) to get the enclosures, firmware, PCB and antenna design, and SDK just right. But we'd rather change the shipping date than compromise on product quality. While in software development you can go with the 'f--- it, ship it' mantra and fix stuff with rapid release cycle, it doesn't really apply to hardware.
The initial hurdles are behind now and we're shipping a lot of Estimote Stickers daily now, burning through the backlog fast. All pending pre-orders should ship by the end of Spring, or in early Summer at the latest. You can send me your order number to wojtek[at]estimote[dot]com and I'll check what's the status and when it's going out.
Same here, I preordered the sticker September 2014 but still nothing. I lost faith in getting them so I moved forward with other solutions, even if I still would like to have them around my house.
As a team lead, I have trouble coming up with a unifying theme for a sprint (2 weeks). My team is about 4 devs, 2 qa, a product owner, and myself (tech lead).
If we devote a sprint to finishing a cohesive goal, I find it extremely likely that some team members will be twiddling their thumbs for extensive periods of time. Or that team members will need to re-work stuff to fit with a key piece, which I consider even worse than thumb twiddling.
Do other teams experience this? How do you deal with it?
I try to have 1-2 big goals (stories) for the team in a sprint, and a few smaller, unrestricted ones as well. If we get blocked on the bigger stuff, the smaller stuff is ready to get knocked out.
If you're accomplishing cohesive, important goals with your sprint, why do you care about thumb twiddling or some refactoring?
If those doing the thumb twiddling are important team members who are tangential to this sprint, why not offer them a bonus vacation or something else morale boosting that doesn't require their butt to be in a seat when it's not necessary?
If they're not really helping you accomplish any important goals, why are they on your team?
All that said, it sounds like you've already struck a pretty good balance between accomplishing big goals and taking care of small but necessary stuff.
I avoided this article for a while because I thought it was going to be about mediocre devs copying-and-pasting code from development blogs into 'enterprise' software and the impact that it had on morale, or culture, or whatever.
What a pleasant surprise!
It did quickly remind me of Amazon's 'press release driven development'. I appreciate the desire to promote, but I wish some popular, public art was credited.
I like this approach's writeup for several points it makes. 1) Planning ahead and framing your definitions through a deep engagement helps developers focus through understanding their work and it adds to their motivation. 2) Consistent engagement with users helps with adoption. 3) Code is only part of the picture, and a release produces ongoing opportunities for improvement.
In terms of 1, within Drupal's developer community, I remember an aphorism, "Talk is silver, code is gold", which served to promote valuable productions over endless discussions. Then, someone took that and a general feeling of a need for foresight before hasty implementation and said, "Talk is silver, code is gold, and planning is diamonds."
In terms of 2, for free software and community projects in general, I get a sense that this approach aligns with stakeholder engagement[0] toward empowering active developers with broad community feedback through timely awareness and helps community cohesion, as well as user empowerment.
On a brief theoretical view of this aim to align shared interests, this approach strikes me as an appropriate response to dramaturgical awareness. In terms of impression management[1], I get a sense that contributors generally want users to see them as involved for good cause and effect, and users want to be seen as grateful, willing participants (hence comments sections on release posts with floods of thank yous). This outlet seems like one way to deepen this two-way information flow.
Wholeheartedly agree! We never publish a blog post before the feature actually is live. We want people to be able to immediately go ahead and play with the it—which is also why we treat these posts as mini-readmes, i.e. we always try not only to paint the story behind the feature, but also do a short intro to how to get started (code snippets etc.)
Isn't there a risk by the time you finish the blog post, someone has posted an even newer JS or Go framework in Grithub, and you have to simply replan the whole tech to use it!
I have a feeling you didn't even read the article and instead interpreted the headline to mean "we use whatever technology generates lots of blog posts," which was my interpretation too, prior to reading the article which is describing what's actually a pretty good approach.
Piotr, Tech Evangelist @ Estimote here. We try to mitigate any of such risks by:
(a) we'll start the sprint with an outline of a blog post, a few key points, and a general theme. Then we get to work, and as we're approaching the grand finale, we start drafting the post. It actually always surprises us—when you start describing something in more detail, you bump into a whole set of "hmm, we didn't think of that", "this could use better docs", "oh wow, that part really is exciting" etc. So it does us a ton of good in terms of polishing the feature we're about to release, but at the same time doesn't block us from moving forward with the implementation.
(b) but really, the rule we try to live by the most is to ship fast and often. A feature doesn't need to be perfect, we're shooting for an MVP. Sounds like a cliche, I know, but it works great for us. Long gone are the days when we'd debate, "maybe a few more RESTful endpoints for these new analytics, maybe a few more filters". Now we'll just ship it and start measuring traction & listening to feedback. If people want more, great, if not ... uh, at least we didn't waste time and can get back to the drawing board (:
