Christian Sepulveda's Blog

November 19, 2005
ANN: Website Facelift and New Blogs

I have updated my website and blog. I've created three blogs: my personal blog, ramblings about agile software development and my thoughts on Web 2.0. The feeds are also updated, but the old blog links and feeds still work, though I recommend that you update to use the new feeds, for those that are actually reading.

There may be some cross-posting and updates to existing entries as a I finish the reorganization. Let me know what you think of the changes.

I hope you enjoy reading.

Posted by csepulv at 10:41 PM | Comments (0)


November 16, 2005
The Power of the Collective Brain

Every now and then someone makes a call for collective brain power; it may be someone in a blog posting or a CEO addressing his staff. The odd thing, at least to me, about such requests is that they frequently occur after some suboptimal individual attempt at solving the original problem. This seems inefficient; why wait as a last resort to call on the power of a collective conscious?

The simple answer is one of resource allocation and opportunity cost; it is inefficient to always point some collective at every issue when a subset can solve the problem. However, agile environments offer an alternative. The high visibility and communication of requirements, risks and decisions provides the opportunity for an opt-in application of collective brain power. Team members can choose to give background thinking to a topic, while not consuming everyone with it.

This isn't necessarily a fully baked idea, but something I've observed with more than one agile team. It is not often there is the explicit call for ideas, yet is seems like many decisions have the benefit of input from multiple people. Besides being egalitarian and empowering it generally leads to good outcomes.

Posted by csepulv at 02:33 PM | Comments (0)


Agile 2.0 and Web 2.0: A Perfect Match

Okay, so my title may be little exaggerated, especially since there isn't officially an Agile 2.0. However, for the agile development community, there are many shifts, trends and new ideas that make it feel like a new generation of agile development. (More on this later.)

Anyway, I've been following some of the Web 2.0 developments lately; I've read many blog posts (http://web20workgroup.com is a good place to start for those interested), heard gossip about VC funding, and know a few people working on Web 2.0 projects. All of this information makes me think an agile approach is perfectly matched for the development of Web 2.0 applications.

Agile development emphasizes the need for feedback, discovery and adaptation. A common agile credo is "release early, release often." Agile development is basically a genetic algorithm (for more on this, read this post); an agile approach evolves its software. Evaluating the "fitness" of the application with each iteration is critical. Real user feedback is one of the best indicators for making such an evaluation.

Most Web 2.0 projects (or at least those I have seen) are consumer oriented. Consumer oriented, service-based software markets are generally accommodating (and sometimes welcome) frequent releases, assuming each release is at least as good and as stable as the previous. Agile development favors short iterations and core practices such as automated testing and continuous integration develop the ability to release early, often and reliably as a core competency of its adopters.

Most projects in early stages are based on a vision and skeleton of a possible solution; success is largely determined by how quickly the application can evolve into what user's need. Quick delivery is necessary to compete and not miss windows of opportunity. I think the best software process to support this is based on an agile model. One of my former clients (when I was a consultant) believed this as well and feels that their agile adoption was a key facilitator of their IPO last year. I also know some very large, high profile, Bay Area web companies who are adopting agile software development and see it as necessary to remain competitive.

I think others support the complementary nature of agile and Web 2.0; the canonical book on Ruby on Rails, one of the popular Web 2.0 enabling technologies, is Agile Web Development with Rails. It describes how Rails development embodies and accommodates an agile approach.

I noted that I believe the agile community is undergoing Agile 2.0. Last year the 2nd edition of the XP white book was published, in which Kent Beck revised and updated his description of XP. Mary Poppendieck's keynote address at XP/AU 2004 described agile as "crossing Moore's chasm"; it is shifting from early adopters to mainstream. While some feel this shift may water down agile, I think it can amplify its effectiveness; many in the agile community have updated and evolved their ideas to better support the software development process.

Finally, I have also adopted a more mature understanding of agile development. I've had many successes in my career applying agile methods, but have been challenged in my current job and our agile adoption. These challenges have caused me to reflect on many assumptions and ask many questions. Though I have more questions than resolutions (which I think is a good sign you are actually learning), my understanding and application of agile software development has evolved into its own "next generation." I know a few others who share many of my ideas and are working in the Web 2.0 space. For these instances, I am excited to see how the combination of Agile and Web 2.0 turns out.

Posted by csepulv at 02:18 PM | Comments (0)


November 11, 2005
Fitness Functions and Agile Development

Agile development is structured on iterative and adaptive development. The application evolves over time and, at least hopefully, closer matches the user's needs. The basic process of agile development is a genetic algorithm; after each iteration, adaptations are made and the whole process repeats with each iteration.

The success of a genetic algorithm generally depends on the quality of its fitness function. A fitness function evaluates the success, or "fitness", of a given result. Within agile development, the iteration boundary marks an opportunity to evaluate product backlogs, prioritize features, and generally tweak the process; both the product and the process evolve.

In order to have a successful agile project, it is imperative to have fitness functions for evaluating both the application being developed and the process by which it is developed. The agile community provides various guidelines for the process evaluation; retrospectives, cost of change, quality of team dynamics, test suite run time and size, shrinking code bases, etc. are all assessment tools and indicators of process health. However, there is little information about evaluating product health.

There are some obvious indicators and questions: do users like it, are bug counts low, is the product selling? I think these are symptoms of the relative health of the application, but I think you need more from a suitable fitness function, particularly when the product isn't an instant and obvious success.

For example, prioritizing features can be a very difficult activity; users will typically assign many features a "number 1" priority. However, ranking each feature in strict order, with no duplicate priority, is a challenge.

While the assessment of the product's health can be seen as a marketing or product management activity, I do not think it is outside the scope of agile development. Successful projects depend on the collaboration of cross-functional teams. Thus, I think it is important to communicate the fitness criteria for an application amongst all on the team, even if one group has primary ownership of it.

Ultimately, the fitness function for an application is an answer to the question of "why do we build the products we do?" Do you know the answer to this question for your current project? Ask others and you may be surprised at the responses.

Posted by csepulv at 02:58 PM | Comments (0)


Agile, Waterfall and Core Assumptions

Superficially, there are many ideas and practices that are in common with agile development and waterfall development. There is a Agile Unified Process, for example and an "XP plugin" for the Rational Unified Process. However, I think agile development is quite different than waterfall, though it is not always easy to name the differences and understand why drawing strong distinctions matters.

I think agile and waterfall are each based on a fundamental assumption; if you subscribe to this idea then you probably should adopt that process. The assumption is about how to achieve a successful software project.

For waterfall development, I think the basic assumption is that perfect planning leads to optimal results. Agile assumes is that an adaptive and evolving approach is the way to go.

I do not think anyone who adopts waterfall actually thinks perfection is attainable, but I think the entire process is aimed at the pursuit of a perfect plan. Extensive requirements, complete with test traceability, elaborate architectures, long analysis and design phases, and up-front test plans are attempts at precise, accurate plans. Usability, overcoming technical challenges and meeting deadlines are achieved (or so is the idea) by building a plan that satisfies these requirements.

By contrast, agile development tends to be lightweight on planning. There is a general pragmatism to "do as little as you can get away with" when considering planning, requirements capture, architecture and documentation, as emphasizing planning would emphasize a different base assumption. However, agile development, in particular XP, is very heavy weight when it comes to automated testing; tremendous effort is usually expended. The reason is the emphasis on adaptability and evolution. Agilists assume change is a necessary and inevitable and agile processes encourage developing your "accommodate-change muscles." Thus, automated tests tend to be a primary mechanism to achieve efficient regression testing, which accommodates code design changes, for example.

Anyone who reads my blog knows I am very biased towards agile development. Though it may sound arrogant and obnoxious, I think many of the practices of waterfall are based on myths and thus make the process flawed. For example, the practice of software architecture is the application of learned patterns and principles in an attempt to satisfy functional and non-functional requirements. The problem is that technology changes quite fast and the software industry is too immature; it is hard to successful apply experience when the rules, constraints, and contexts are in flux. For at least the foreseeable future, I think you are better served with a process that allows for discovery and adaptation than depends on rare constants.

Posted by csepulv at 01:57 PM | Comments (0)