Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

June 05 2013

April 06 2012

Four short links: 6 April 2012

  1. FBI Uses Agile (Information Week) -- The FBI awarded the original contract for the case management system to Lockheed Martin in 2006, but an impatient Fulgham, who was hired in 2008 to get the project on track, decided to bring it in house in September 2010. Since then, the agency has been using agile development to push the frequently delayed project across the finish line. The FBI's agile team creates a software build every two weeks, and the pre-launch system is now running Build 33. The agency is working on Build 36, comprised mainly of features that weren't part of the original RFP. Fulgham says the software is essentially done.
  2. Lucky Meat (Matt Webb) -- the man is a mad genius. If you believe "mad" and "genius" are opposite ends of a single dimension, then I will let you choose where to place this post on that continuum. Then when you choose your tea (or coffee), the liquid is shot as if through the barrel of a gun BANG directly at your face. We use facial recognition computer chips or something for this. It blasts, and splashes, as hard and fierce as possible. And then the tea (or coffee) is runs down the inside slope of the "V" and is channeled in and falls eventually into a cup at the bottom apex where it finally drips in. Then you have your drink. (But you don't need it, because you're already awake.)
  3. Quietly Awesome -- how are your hiring processes biased towards extroverts? See also I don't hire unlucky people.
  4. How We Will Read (Clive Thompson) -- Clive is my hero. I feel like we see all these articles that say, “This is what the e-book is,” and my response is always, “We have no idea what the e-book is like!” All these design things have yet to be solved and even thought about, and we have history of being really really good at figuring this out. If you think about the origins of the codex — first we started reading on scrolls. Scrolls just pile up, though. You can’t really organize them. Codexes made it easier to line them up on a shelf. But it also meant there were pages. It didn’t occur to them for some time to have page numbers, because the whole idea was that you only read a small number of books and you were going to read them over and over and over again. Once there were so many books that you were going to read a book once and maybe never again, it actually became important to consult the book and be able to find something inside it. So page numbers and indices became important. We look at books and we’re like, “They’re so well designed,” but it took centuries for them to become well-designed. So you look at e-books, and yeah, they’re alright, but they’re clearly horrible compared to what they’re going to be. I find it amazing that I can get this much pleasure out of them already. AMEN!

March 30 2012

Top Stories: March 26-30, 2012

Here's a look at the top stories published across O'Reilly sites this week.

Designing great data products
Data scientists need a systematic design process to build increasingly sophisticated products. That's where the Drivetrain Approach comes in. (This report is also available as a free ebook.)


Five tough lessons I had to learn about health care
Despite the disappointments Andy Oram has experienced while learning about health care, he expects the system to change for the better.


A huge competitive advantage awaits bold publishers
"The Lean Startup" author Eric Ries talks about his experiences working with traditional publishing structures and how they can benefit from lean startup principles.

The Reading Glove engages senses and objects to tell a story
What if you mashed up a non-linear narrative, a tangible computing environment and a hint of a haunted house experience? You might get the Reading Glove, a novel way to experience a story.


Passwords and interviews
A candidate that forks over a social media password during an interview could become an employee that gives out a password in other situations. Employers aren't making that connection.


Fluent Conference: JavaScript & Beyond — Explore the changing worlds of JavaScript & HTML5 at the O'Reilly Fluent Conference, May 29 - 31 in San Francisco. Save 20% on registration with the code RADAR20.

Ambulance photo: Ambulance by plong, on Flickr

February 23 2012

Agile for real-world publishing

At TOC, you're as likely to run into media professionals, entrepreneurs and innovators as you are publishers, booksellers and others working in traditional publishing. This, in turn, makes the underlying themes as varying and diverse as the attendees. This is the first in a series, taking a look at five themes that permeated interviews, sessions and/or keynotes at this year's show. The complete series will be posted here.


Agile publishing, in terms of workflow, work environment as well as practical publishing applications was one of the overriding themes at this year's TOC.

Kristen McLean (@ABCKristen), founder and CEO of Bookigee, addressed agile in her session Hippo In Ballet Shoes, Or Greyhound On The Track? Applying Agile Methodologies To Traditional Publishing. She talked about how agile is a workflow strategy and cited "The Agile Manifesto":

AgileManifesto.jpg

She also discussed what the agile environment looks like in real-world publishing. Some highlights from her discussion include:

  • Self-organizing teams with flexible skills — get highly talented and interdisciplinary individuals
  • Accountability & empowerment — Give them what they need and trust them to get the work done.
  • Sustainable development, able to maintain a constant pace — each person should be able to commit only to what they can do in a day, a week, or a production cycle. Cut back features in order to deliver on time.
  • Face-to-face conversation is the best form of communication (co-location) — put the entire team in one place.
  • Completed tasks are delivered frequently — weeks rather than months
  • Completed tasks are the principal measure of progress — focus on real stuff, not on rituals, documentation, or other internal benchmarks that do nothing for your customer.

McLean's presentation slides can be found here, and an interview with McLean on some of the finer points of agile can be found here.

Firebrand Technologies' communications chief Laura Dawson (@ljndawson) held a session on metadata, Metadata is Not a Thing, that reinforced some of these ideas, in that an agile publishing environment requires solid metadata through every phase of the publishing process. Dawson talked more about metadata and workflows in a video interview:

The agile theme flowed in a practical direction in the Real World Agile Publishing session with Joe Wikert (@jwikert) of O'Reilly Media and Dominique Raccah (@draccah) of Sourcebooks, and moderator Brett Sandusky (@bsandusky) of Macmillan New Ventures.

Wikert talked about a variety of agile publishing projects at O'Reilly, including current book projects such as Todd Sattersten's "Every Book Is a Startup," which is based on a model of frequent updates to build content and dynamic pricing, and Peter Meyers' Breaking the Page, which is based on a freemium model. He also addressed other styles of agile publishing O'Reilly has experimented with, including early release projects and rough cuts, which offer early digital access and flat pricing. Wikert touched on short form content publishing as well, which he said allows for a quick turnaround to publish minimum viable products on cutting-edge topics.

Raccah announced that Sourcebooks would be using an agile publishing model to publish an upcoming book, "Entering the Shift Age," by David Houle. She outlined three goals for the model — more efficient product development, a better author experience, and more timely/updated books — and listed six guiding principles of agile publishing:

AgileGuidingPrinciples.PNG

Wikert's presentation slides can be viewed here, and Raccah's can be viewed here.

In a separate video interview, Sandusky addressed a question about whether agile applies universally to all types of books:

"'Books' is the part that I have a little bit of a problem with — I think agile applies universally to all kinds of digital product development. That could include books; that could include traditional print books with a POD component; that could include many different types of digital products. 'Books,' in terms of the traditional model of 'build a print book, take it to manufacturing, and then take it to launch' is not an agile process. But if your workflow is more digitally focused, then I think it applies to all digital products overall."

Also in a video interview, Todd Sattersten (@toddsattersten), author of "Every Book is a Startup" and founder of BizBookLab, addressed a question about how publishers can apply agile development methods:

"I'm interested in how we take the concept of a minimum viable product and apply it to how we develop content. The problem with books is that we tend to believe they have to be big and long and carefully constructed. With minimum viable product, it's really the exact opposite — what is the smallest amount that we have to do? It could be just putting up a splash page and saying, "Are you interested enough in this idea to share an address?" We're very familiar in book publishing with the idea of pre-sales — why not sell a book before we actually invest a whole bunch of money in producing the book?"


If you couldn't make it to TOC, or you missed a session you wanted to see, sign up for the TOC 2012 Complete Video Compilation and check out our archive of free keynotes and interviews.


Related:


Reposted byRKvitaminb

February 13 2012

There's Plan A, and then there's the plan that will become your business

We need a word that captures the specific sort of pain entrepreneurs feel when their carefully developed startup ideas are met with blank indifference. All that time. All that effort. And it adds up to ... this?

"Running Lean" author Ash Maurya (@ashmaurya) doesn't have that word, but he may have something better: a method for avoiding the pain altogether. In the following interview, Maurya explains how the Running Lean process helps startups iterate from flawed "Plan A" ideas to products people want.

What is Running Lean?

Ash MauryaAsh Maurya: Running Lean is a systematic process for quickly vetting and building successful products. Most entrepreneurs start with an initial vision: their "Plan A." Unfortunately, most Plan A ideas don't work. Running Lean helps entrepreneurs iterate from their initial Plan A to one that works — before running out of resources.

What are the early signs that a Plan A idea isn't working?

Ash Maurya: A startup is about bringing bold, new ideas to the world. That naturally works to your advantage. Your initial goal is getting a strong signal (positive or negative) from customers. This typically doesn't require a large sample size. So, for instance, if you can't even get 10 strangers to say they want your product (or better yet, pay for your product), this problem is not going to go away by targeting 1,000 people. A strong negative signal indicates that your bold hypothesis most likely won't work. It lets you quickly refine or abandon it.

On the other hand, a strong positive signal doesn't necessarily mean it will scale up to a significant business. But it does give you permission to move forward on the hypothesis until it can be verified later through quantitative means.

Is there any value to writing a business plan?

Ash Maurya: Before you can start the process of iteration, you have to draw a line in the sand. You have to start by documenting your initial vision (or Plan A) and sharing it with at least one other person. Otherwise, it's too easy to endlessly iterate in your head and never be wrong.

Traditionally, business plans have been used for this purpose. But while writing a business plan is a good exercise for the entrepreneur, a business plan falls short of its intended purpose. Few people take the time to actually read business plans. More importantly, since many Plan As are likely to be proven wrong anyway, spending several weeks or months writing a 60-page business plan largely built on untested hypotheses is a form of waste.

I instead recommend using a one-page business model format called Lean Canvas. It captures the same core elements you find on a business plan, but because it fits on one page, it's a lot more concise, portable and readable.

Running Lean — This book demonstrates ways to apply and test techniques from the Customer Development, Lean Startup, and bootstrapping methods. Learn how to engage customers throughout the development cycle so you can build a product people will actually buy. (Note: This digital early release edition includes the author's raw and unedited content. You'll receive updates when significant changes are made, as well as the final ebook version.)

Why is it a bad idea to build products in stealth?

Ash Maurya: There is a fear, especially common among first-time entrepreneurs, that their great idea will be stolen by someone else. The truth is two-fold: First, most people are not capable of visualizing the potential of an idea at such an early stage; and second, they won't care. The initial challenge for most startups is getting noticed at all.

There is also a difference between stealth and obscurity. Stealth is bad because you build products in complete isolation only to find out later that you were optimizing a product no one wanted. On the other hand, obscurity is a gift. It allows you to test your product at micro-scale, getting it right, before attracting a lot of attention and scaling out.

So avoid stealth, but embrace obscurity.

Do the techniques in your book only apply to tech-centric startups?

Ash Maurya: Even though a lot of these concepts were recently popularized by tech-centric startups, I believe the principles they embody are universally applicable to products ranging from high-tech to no-tech. Several core principles in "Running Lean" date back to the last century when Taiichi Ohno and Shigeo Shingo were laying out the early groundwork for the Toyota Production System, which later became "lean manufacturing." I used these same techniques in the writing of my book, which I share as a case study in the book along with several other non-tech products.

What's the connection between Running Lean and the Lean Startup?

Ash Maurya: Running Lean is a synthesis of three methodologies: Lean Startup, Customer Development, and Bootstrapping. Of the three, Running Lean draws the most from Lean Startup. While the Lean Startup, created by Eric Ries, codifies the core principles, my goal with Running Lean was to create an actionable how-to guide for taking these principles to practice.

[Note: Eric Ries is the editor of the Lean Startup Series, which includes "Running Lean."]

Why did you decide to apply Lean Startup methods to your own work?

Ash Maurya: When I was first exposed to Lean Startup, I was already running a company and on my fifth product at the time. I had built products in stealth; attempted building a platform; dabbled with open sourcing; practiced release-early, release-often; embraced "less is more"; and even tried "more is more" — all with varying degrees of success.

I saw that acting on a vision can easily consume years of your life, and I was in search of a better, faster way of vetting and building products.

The key idea from Lean Startup that resonated with me was that of rapid iteration around customer learning. Specifically, that you could almost always test the riskiest parts of a vision without having to build the product first.

As I started internalizing these principles, I had more questions than answers. That prompted my own rigorous testing and application of these principles, which led to the book "Running Lean" and several other software products I am now building.

This interview was edited and condensed.


"Running Lean" author Ash Maurya will discuss the Running Lean methods in a free webcast on Feb. 14 at 10 am PT / 1 pm ET. Register to attend.



Related:


January 10 2012

How agile methodologies can help publishers

Agile methodologies originated in the software space, but Bookigee CEO Kristen McLean (@ABCKristen) believes many of the same techniques can also be applied to content development and publishing workflows. She explains why in the following interview.

McLean will further explore this topic during her agile methodologies presentation at the upcoming Tools of Change for Publishing conference in New York.

What is an agile methodology?

KristenMcLean.jpgKristen McLean: An agile methodology is a series of strategies for managing projects and processes that emphasize quick creative cycles, flat self-organizing working groups, the breaking down of complex tasks into smaller achievable goals, and the presumption that you don't always know what the finished product will be when you begin the process.

These types of methodologies work particularly well in any situation where you are trying to produce a creative product to meet a market that is evolving — like a new piece of software when the core concept needs proof from the user to evolve — or where there needs to be a very direct and engaged relationship between the producers and users of a particular product or service.

Agile methodologies emerged out of the software development community in the 1970s, but began to really codify in the 1990s with the rise of several types of "lightweight" methods such as SCRUM, Extreme Programming, and Adaptive Software Development. These were all rolled up under the umbrella of agile in 2001, when a group of developers came together to create the Manifesto for Agile Software Development, which set the core principles for this type of working philosophy.

Since then, agile has been applied outside of software development to many different kinds of systems management. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project. At the end of the day, it's about getting something out there that we can test and learn from.

How do agile methodologies apply to publishing?

Kristen McLean: In relation to publishing, we're really talking about two things: agile content development and agile workflow.

Agile content development is the idea that we may be able to apply these methodologies to creating content in a very different way than we are traditionally used to. This could mean anything from serialized book content to frequent releases of digital content, like book-related websites, apps, games and more. The discussion of how agile might be applied to traditional book content is just beginning, and I think there's an open-ended question about how it might intersect with the deeply personal — and not always quick — process of writing a book.

I don't believe some of our greatest works could have been written in an agile framework (think Hemingway, Roth, or Franzen), but I also believe agile might lend itself to certain kinds of book content, like serial fiction (romance, YA, mystery) and some kinds of non-fiction. The real question has to do with what exactly a "book" is and understanding the leading edge between knowing your audience and crowdsourcing your material.

Publishing houses have been inherently hierarchical because they've been organized around a manufacturing process wherein a book's creation has been treated as though it's on an assembly line. The publisher and editor have typically been the arbiters of content, and as a whole, publishers have not really cultivated a direct relationship with end users. Publishers make. Users buy/read/share, etc.

Publishers need to adapt to a radically different way of working. For example, here's a few ways agile strategies could help with the adaptation of a publishing workflow:

  • Create flat, flexible teams of four to five super-talented individuals with a collective skill set — including editorial, marketing, publicity, production, digital/design, and business — all working together from the moment of acquisition (or maybe before). These teams would need to be completely fluent in XHTML and would work under the supervision of a managing publisher whose job would be to create the proper environment and remove impediments so the team could do its job.
  • An original creative voice and unique point of view will always be important in great writing, but those of us who produce books as trade objects (and package the content in them) have to stop assuming we know what the market wants and start talking to the market as frequently as possible.


  • Use forward-facing data and feedback to project future sales. Stop using past sales as the exclusive way to project future sales. The market is moving too fast for that, and we all know there is a diminishing return for the same old, same old.

TOC NY 2012 — O'Reilly's TOC Conference, being held Feb. 13-15, 2012, in New York City, is where the publishing and tech industries converge. Practitioners and executives from both camps will share what they've learned and join together to navigate publishing's ongoing transformation.

Register to attend TOC 2012

This interview was edited and condensed.

Associated photo on home and category pages adapted from: Agile-Software-Development-Poster-En.pdf by Dbenson and VersionOne, Inc., on Wikimedia Commons

Related:

December 17 2009

The Best and the Worst Tech of the Decade

With only a few weeks left until we close out the 'naughts and move into the teens, it's almost obligatory to take a look back at the best and not-so-best of the last decade. With that in mind, I polled the O'Reilly editors, authors, Friends, and a number of industry movers and shakers to gather nominations. I then tossed them in the trash and made up my own compiled them together and looked for trends and common threads. So here then, in no particular order, are the best and the worst that the decade had to offer.

The Best

AJAX - It's hard to remember what life was like before Asynchronous JavaScript and XML came along, so I'll prod your memory. It was boring. Web 1.0 consisted of a lot of static web pages, where every mouse click was a round trip to the web server. If you wanted rich content, you had to embed a Java applet in the page, and pray that the client browser supported it.

Without the advent of AJAX, we wouldn't have Web 2.0, GMail, or most of the other cloud-based web applications. Flash is still popular, but especially with HTML 5 on the way, even functionality that formerly required a RIA like Flash or Silverlight can now be accomplished with AJAX.

Twitter - When they first started, blogs were just what they said, web logs. In other words, a journal of interesting web sites that the author had encountered. These days, blogs are more like platforms for rants, opinions, essays, and anything else on the writer's mind. Then along came Twitter. Sure, people like to find out what J-Lo had for dinner, but the real power of the 140 character dynamo is that it has brought about a resurgence of real web logging. The most useful tweets consist of a Tiny URL and a little bit of context. Combine that with the use of Twitter to send out real time notices about everything from breaking news to the current specials at the corner restaurant, and it's easy to see why Twitter has become a dominant player.

Ubiquitous WiFi: I want you to imagine you're on the road in the mid-90s. You get to your hotel room, and plop your laptop on the table. Then you get out your handy RJ-11 cord, and check to see if the hotel phone has a data jack (most didn't), or if you'll have to unplug the phone entirely. Then you'd look up the local number for your ISP, and have your laptop dial it, so you could suck down your e-mail at an anemic 56K.

Now, of course, WiFi is everywhere. You may end up having to pay for it, but fast Internet connectivity is available everywhere from your local McDonalds to your hotel room to an airport terminal. Of course, this is not without its downsides, since unsecured WiFi access points have led to all sorts of security headaches, and using an open access point is a risky proposition unless your antivirus software is up to date, but on the whole, ubiquitous WiFi has made the world a much more connected place.

Phones Get Smarter: In the late 90s, we started to see the first personal digital assistants emerge, but this has been the decade when the PDA and the cell phone got married and had a baby called the smartphone. Palm got the ball rolling with the Treos about the same time that Windows Mobile started appearing on phones, and RIM's Blackberry put functional phones in the hands of business, but it was Apple that took the ball and ran for the touchdown with the iPhone. You can argue if the droid is better than the 3GS or the Pre, but the original iPhone was the game-changer that showed what a smartphone really could do, including the business model of the App Store,

The next convergence is likely to be with Netbooks, as more and more of the mini-laptops come with 3G service integrated in them, and VoIP services such as Skype continue to eat into both landline and cellular business.

The Maker Culture: There's always been a DIY underground, covering everything from Ham radio to photography to model railroading. But the level of cool has taken a noticeable uptick this decade, as cheap digital technology has given DIY a kick in the pants. The Arduino lets anyone embed control capabilities into just about anything you can imagine, amateur PCB board fabrication has gone from a messy kitchen sink operation to a click-and-upload-your-design purchase, and the 3D printer is turning the Star Trek replicator into a reality.

Manufacturers cringe in fear as enterprising geeks dig out their screwdrivers. The conventional wisdom was that as electronics got more complex, the "no user serviceable parts" mentality would spell the end of consumer experimentation. But instead, the fact that everything is turning into a computer meant that you could take a device meant for one thing, and reprogram it to do something else. Don't like your digital camera's software? Install your own! Turn your DVR into a Linux server.

Meanwhile, shows like Mythbusters and events like Maker Faire have shown that hacking hardware can grab the public's interest, especially if there are explosions involved.

Open Source Goes Mainstream: Quick! Name 5 open source pieces of software you might have had on your computer in 1999. Don't worry I'll wait...

How about today? Firefox is an easy candidate, as are Open Office, Chrome, Audacity, Eclipse (if you're a developer), Blender, VLC, and many others. Many netbooks now ship with Linux as the underlying OS. Open Source has gone from a rebel movement to part of the establishment, and when you combine increasing end user adoption with the massive amounts of FLOSS you find on the server side, it can be argued that it is the 800 pound Gorilla now.

As Gandhi said, "First they ignore you, then they laugh at you, then they fight you, then you win." When even Microsoft is releasing Open Source code, you know that you're somewhere between the fight and win stages.

Bountiful Resources: 56K modems, 20MB hard drives, 640K of RAM, 2 MHz processors. You don't have to go far back in time for all of these to represent the state of the art. Now, of course, you would have more than that in a good toaster...

Moore's Law continues to drive technology innovation at a breakneck pace, and it seems that related technologies like storage capacity and bandwidth are trying to follow the same curve. Consider that AT&T users gripe about the iPhone's 5GB/month bandwidth cap, a limit that would have taken 10 solid days of transferring to achieve with a dialup connection.

My iPhone has 3,200 times the storage of the first hard drive I ever owned, and the graphics card on my Mac Pro has 16,000 times the memory of my first computer. We can now do amazing things in the palm of our hands, things that would have seemed like science fiction in 1999.

The Worst

SOAP: The software industry has been trying to solve the problem of making different pieces of software talk to each other since the first time there were two programs on a network, and they still haven't gotten it right. RPC, CORBA, EJB, and now SOAP now litter the graveyard of failed protocol stacks.

SOAP was a particularly egregious failure, because it was sold so heavily as the final solution to the interoperatibility problem. The catch, of course, was that no two vendors implemented the stack quite the same way, with the result that getting a .NET SOAP client to talk to a Java server could be a nightmare. Add in poorly spec'd out components such as web service security, and SOAP became useless in many cases. And the WSDL files that define SOAP endpoints are unreadable and impossible to generate by hand (well, not impossible, but unpleasant in the extreme.)

Is it any wonder that SOAP drove many developers into the waiting arms of more useable data exchange formats such as JSON?

Intellectual Property Wars: How much wasted energy has been spent this decade by one group of people trying to keep another group from doing something with their intellectual property, or property they claim was theirs? DMCA takedowns, Sony's Rootkit debacle, the RIAA suing grandmothers, SCO, patent trolls, 09F911029D74E35BD84156C5635688C0, Kindles erasing books, deep packet inspection, Three Strikes laws, the list goes on and on and on...

At the end of the day, the movie industry just had their best year ever, Lady Gaga seems to be doing just fine and Miley Cyrus isn't going hungry, and even the big players in the industry are getting fed up sufficiently with the Trolls to want patent reform. The iTunes store is selling a boatload of music, in spite of abandoning DRM, so clearly people will continue to pay for music, even if they can copy it from a friend.

Unfortunately, neither the RIAA nor the MPAA is going gently into that good night. If anything, the pressure to create onerous legislation has increased in the past year. Whether this is a last gasp or a retrenchment will only be answered in time.

The Cult of Scrum: If Agile is the teachings of Jesus, Scrum is every abuse ever perpetrated in his name. In many ways, Scrum as practiced in most companies today is the antithesis of Agile, a heavy, dogmatic methodology that blindly follows a checklist of "best practices" that some consultant convinced the management to follow.

Endless retrospectives and sprint planning sessions don't mean squat if the stakeholders never attend them, and too many allegedly Agile projects end up looking a lot like Waterfall projects in the end. If companies won't really buy into the idea that you can't control all three variables at once, calling your process Agile won't do anything but drive your engineers nuts.

The Workplace Becomes Ubiquitous: What's the first thing you do when you get home at night? Check your work email? Or maybe you got a call before you even got home. The dark side of all that bandwidth and mobile technology we enjoy today is that you can never truly escape being available, at least until the last bar drops off your phone (or you shut the darn thing off!)

The line between the workplace and the rest of your life is rapidly disappearing. When you add in overseas outsourcing, you may find yourself responding to an email at 11 at night from your team in Bangalore. Work and leisure is blurring together into a gray mélange of existence. "Do you live to work, or work to live," is becoming a meaningless question, because there's no difference.

So what do you think? Anything we missed? Hate our choices? With us 100 percent? Let us know in the comments section below.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!

Schweinderl