Where Science Meets Art
In part one of this article, I asked the simple question, “Is software development more like building a bridge or painting a picture?” The answer is both. The rest of that article shows how extreme programming has helped to make software development like building a bridge by introducing sound foundational engineering practices. In part two, I will show how agile principles support the artistic nature of software development. This is where agile really shines.
Imagine you are Michelangelo and the Pope wants a grand scene of creation on the ceiling of the Sistine Chapel. He has a God-given vision and you are charged with making it a reality. The Pope knows what he wants but does not have the skills to create it. You have the skills, but not the vision.
So, you assemble your artists, interview the Pope and sketch your interpretation of his vision. After many iterations of sketching, you present an image that has the Pope very excited.
Now you and the crew go to work, starting with the primary image of God and Adam. Every day, the Pope reviews your progress and wants adjustments. You welcome this, as you want to get it right. He leaves the details to you and how to make it all come together but he is very sure of the overall vision.
Once you finish the primary picture, you start sketching the other images and repeat the process. Note the repeated cycle of rapid feedback and iteration after iteration of trial and error. Note how even while painting the ceiling, you make adjustments to capture the vision. You would never build a bridge this way. Instead, after years of engineering, you create a detailed project plan, begin the construction of the bridge and change only to deal with technical issues you encounter, never the end form.
Software is like the Sistine Chapel ceiling. There is a CEO or entrepreneur who has a vision for a product, but very few specifics. Following the agile approach, you start with simple sketches and iterate using prototypes and small pieces of the end product to see if you are capturing the vision. You have daily stand-ups with the owner and demos every two weeks. Once the owner has something to see and touch, you move on to more features.
As soon as you get to a minimum viable product (MVP), you release that software so the owner can start gaining value from it. As users work with the product, the owner gets feedback that leads to new features. You build these new features and refactor old ones. You set up a forum for users to validate new features before release. When it’s time for the next phase, you repeat the cycle of feedback and incremental development until the MVP is released. This process continues until you have achieved the entire original vision.
Note a major difference between software and paintings. Once a painting is done, the work is finished. Once the initial MVP is done, the work is just beginning. The product will start to take on a life of its own as the community of users influences the product’s evolution. Agile approaches to software development best handle this dynamic. This is why agile works.
Authors note: the story of the Sistine Chapel painting is a fictional account of the events but is based on actual practices of the day for commissioned works of art.
