Whereas modern product cycles rely on shorter cycles, something along the lines of this diagram:

The assumption in modern approaches is that the road to good software is shorter when making smaller steps and frequent turns than when making large steps and more radical turns. (This is geometrically true in the diagrams…)

Old-style product cycles consisted of three main steps: planning (negotiation, prioritization, scheduling), development (design, coding, testing) and launch (alpha/beta, release, outbound marketing). The main question I was trying to tackle in the talk was how the corresponding activities map to product cycles with frequent releases.

On a side note, some organizations use old-style product cycles (infrequent software releases) while using “agile development” techniques internally (that is, frequent internal releases). While perhaps better than nothing at all, this approach misses—in my mind—much of the benefit in agile software development. In the end of the day, the biggest benefit is adapting to customer feedback, and without the software reaching real customers, value diminishes.

The areas I was trying to tackle in the talk were:

How does planning occur in an environment when there’s no defined period for planning (“beginning of the release”)? When the working assumption is that many of the details (and associated effort) will be revealed during the development process. And, how do roadmaps look in such an environment?

How do product launches occur in an environment when there’s no defined period for launch, but—instead—software is ready in chunks? How and when does customer feedback get incorporated into the cycle?

How does one integrate new approaches and opportunities brought about by agile development? Mostly, agile approaches facilitate experimentation through proof-of-concepts and such (with various variants such as MVP, MSP, and lean).

In case you’re in the Tel Aviv area on Jan. 30, 2013, you’re most welcome to drop by the Agile Practitioners 2013 conference. I plan to deliver a talk titled Product Roadmap, Planning and Launch in an Agile Environment.

The talk will revolve around the fact that in an Agile environment, predictability is knowingly sacrificed for flexibility. Agile practitioners assume that what’s being development changes along the way, and that the true effort associated with each new development is only revealed during the development process. They knowingly release new product functions in smaller chunks. And, they empower individuals and let them drive the process. This essentially makes traditional approaches for managing product roadmaps and launches obsolete.

I plan to cover some approaches and techniques in managing a product in an Agile environment, highlighting some examples from our experience at Webcollage, delivering a SaaS product to a large number of high-profile customers. The current plan is to touch various angles of the conflict, from planning (internal vs. external roadmaps, hard vs. soft commitments), conflict resolution (emergency and time-sensitive issues), release and rollout management (soft vs. official launches, gradual rollout, alpha/beta cycle and feedback management), as well as some additional areas as time allows (documentation).

At WebCollage, we are releasing a new version of our SaaS based solution to our customers every two weeks. We released 23 versions in 2011, and will be releasing the 6th version of our software over this upcoming weekend. In other words, we are firm believers in agile development and in its ability to help obtain continuous market feedback (here’s a previous post on this topic).

For various reasons, though, agile development has become somewhat synonymous with one specific approach, namely Scrum. Realizing that Scrum is widely accepted, I previously expressed an opinion that Scrum is perhaps an interesting recipe, but is far from being the best approach to SaaS agile development (and web application development in general). I have received quite a lot of feedback on that other post, some with contrarian views arguing that Scrum is perhaps a silver bullet after all.

There’s always something to be said for using the most popular approach. As an old IT saying goes, no one ever got fired for buying IBM. In this regard, there are intrinsic advantages to using Scrum, most notably the industry ecosystem: ability to easily find knowledge, share best practices, etc.

Insomuch as the actual methodology goes, though, there are simply better alternatives for many software development scenarios. Here’s a sketch of how we at WebCollage develop software, and the advantages it has over Scrum. Our approach is an adaptation of Kanban/Lean software development.

As I had mentioned in a previous post, we are now actively hiring software developers to our development center in Tel Aviv, Israel.

As part of the interviewing process, we see software developers (and other candidates) look at various alternatives, and having a hard time to decide on a potential direction for their software career. The decisions are naturally harder for young developers who haven’t yet established some career path; but, I’m sometimes surprised to see senior engineers who seriously look at options very distant from one another, such as (as one example) building security devices vs. building web applications.

Here’s my two cents on things to look for in starting (and building) a career in software. Some of the considerations below are specific to engineering positions (developers and testers) but many are as applicable to additional roles such as product management, project management, product marketing and at times sales.Continue reading →

As I had mentioned in a previous post, I believe that software-as-a-service vendors must adopt an agile development and release methodology to release software on a very frequent basis.

Interestingly, we at WebCollage have been recently hiring engineers to our Development Center in Tel Aviv (here’s a short promotion to our careers page). Perhaps not surprisingly, many of the people we interview have touched the Scrum development methodology in some way or form. Given the ubiquity of Scrum, it’s surprising how little discussion there is on why Scrum misses the mark when it comes to developing SaaS applications or web applications in general.

Like many software organizations, we had used Scrum in the past, and here’s why we feel it’s not the right tool for SaaS vendors.

Agile Software Development is continuously gaining momentum in the last decade since the introduction of the Agile Manifesto in 2001. Software-as-a-service (and cloud-based web applications in general) is also gaining momentum in the last decade, roughly during the same period. Is this a coincidence?

Time and again, the technology landscape exhibits parallel fast advancement of synergetic technologies and methodologies.

For example, in the late 90’s, my colleague Elan Dekel has started a company called EarthNoise, offering a video sharing website. Sounds familiar? In 1995, a company called YouTube was founded with a similar idea. It was acquired in 2006 by Google for $1.65b. EarthNoise, on the other hand, went out of business as early as 2001. In the four years that passed, broadband internet access became popular, and so did digital video cameras. The three areas—video sharing, digital cameras and broadband internet—evolved hand in hand to create a new phenomena—user generated video on the web. The ability and desire to share videos online drove increased adoption of broadband internet and digital video cameras (and yielded brand new products such as the now-defunct Flip). The increased consumer demand for broadband and cameras drove down prices and accelerated technology advancement. This in turn increased adoption of video sharing sites. Now, video sharing sites are an inseparable part of our lives.

Arguably, the success of the iPhone is—similarly—largely due to technologies that co-evolve with smartphone advancement: 3G connectivity, Wi-Fi connectivity, touchscreen technology, low-consumption processors and—at least to a certain degree—HTML5.

I would assert that software-as-a-service and agile development methodologies are likewise coevolving and drive each other’s adoption. It may not be obvious, but this creates a spiral effect (or—in Geoffrey Moore’s terms—a tornado) of disruptive innovation that will eventually displace many of the software development paradigms.