Was Leonardo da Vinci Agile?

Was Leonardo da Vinci Agile?

We all might be familiar with Leonardo di ser Piero da Vinci the great Italian polymath

who is world famous for his Mona Lisa portrait. He was also known as a man of "unquenchable curiosity". Perhaps

this curiosity might have led him to a perfect way making his world famous Mona Lisa portrait.

It has been said that Leonardo would first create a detailed under painting and then apply his colors in transparent glazes on top. If we put ourselves in Leonardo da Vinci's shoes for a moment, what would be our strategy with the goal of being commissioned for the painting? Would you sketch the whole drawing i.e. the lady sitting on a chair with a smile and the background and then paint it or would you first just focus on the lady's face - sketch it and paint it completely and polish it, then focus on her hands - sketch them and paint and polish it completely and then her dress and so on?

In agile software development (of web content especially) we are often faced with this same question. Well the answer really completely depends on the core and non core features of your product and your release strategy/plan. Every product has a release done criteria. The release done criteria is derived from the release plan and the release plan is derived based on the nature of the product, it's core and non core features and their work flow. How the users would really use the product is key to know here.

To speak with more realistic deta

il, here is an example. Now think of a shopping website with several screens that shoppers access. Every screen would have a bunch of features. Some of those can be broadly classified as core features and non core features. A Core feature would be a feature without which a website or web app would have no value. For example, not being able to login or create your own account, select a product and check ou

t and by being able to make a payment would make a shopping website useless and would be in

valuable to both the shoppers and the shopping website! Now a non core feature could be having the option of a speedy checkout or having the benefit of viewing similar kind of products as prompts or reminders before actually making the final payment. The core and

non core features would change based on several factors like the market, the users current trend of needs, events etc. These identified core and non core features would drive sequence of work to come in iterations and also the done criteria for the iteration.

Moving back to the painting example, lets assume that Le

onardo might have had to pick out the core pieces in his potrait of mona lisa while discussing the initial vision of the painting with the commissioner, so what would they be? Would it be the lady herself, her face, her elegant smile, her crossed hands, her hair, her dress? Would the background, the landscape, the trees, the chair the lady is sitting on be n

on core features? That is what it seems like but I am no artist, so I'll try not to answer that question but the key point here is that knowing the core features that would drive the product and shipping them out first is most essential. What is even more important to know is that the core features compliment each other and cannot be released or shipped without one another. For eg. a login to web app feature would not make sense to be shipped without a check out feature screen.

So what do we do?

A technique which has worked for me in the past is building the core features and making the complete workflow functional and "working software" iteratively. Rather than building one functional core feature and polishing it till it's shippable, build the the set of core features based on the release plan even though they are not polished in the first iteration, and then use the next iteration to tweak the work flow based on customer feedback, then polish the whole thing and make it shippable. This is a common sense way of doing things. We know as a fact that certain collections of core features are just needed (together) to be able to call a product 'shippable' so why silo the core feature building process?

The non core features may also be squeezed in at times as long as it is in the release plan, but what is more important to focus on here is a technique to do incremental and iterative software development most efficiently, while using common sense.