- Posted by dan on March 13, 2011
When we think of Leonardo da Vinci most of us think about him as an artist, most famous for the Mona Lisa. But as you probably know he did far more than that within his lifetime. What he's not so famous for are his sketches, or drawings, when you look at some of them and consider the time period from which they're from though it's amazing.
There's detailed drawings of human anatomy, there's sketches of flying machines, tanks even depictions of using solar power to heat water.
How does this relate, to software development? Well my point is as appreciated and amazing his drawings are, what people remember are his paintings.
At work we use Scrum as our agile methodology but common to almost all the agile methods is the iteration. This is the realisation that massive up front design often doesn't work, and reduces your ability to react to Market forces. So agile with it's relatively short iterations which deliver working software on a more regular basis is very much a good thing; working software over comprehensive documentation
, as the agile manifesto
We have what are essentially monthly release cycles, though we try and plan at a weekly cycle. So our sprints are 1 week. We'll go into backlogs and we'll discuss the new stories on the backlog, and size the stories, which the product owner can then prioritize.
We've even started to have mini inceptions
(a few days as opposed to a week) for larger themes of work. We plan a solution, make the stories, size them prioritise them.
The problem we find, is that the cooler more technically interesting features, from a development standpoint are often put as lower priorities.
Product owners are happy with a product that enables their team to do the job, but requires what we as technologists think of as lots of manual intervention. We end up planning lot of bells and whistles and crucially buttons to press. But the crucial part, is left up to the business to decide. There's absolutely nothing wrong with that, but as a technical person I feel we should raise the level of abstraction and try to better inform them of what might be a good position to set the dial to.
We settle on a minimum marketable feature set
. This is our world nearly always needs to try and be delivered inside one release, to start realising the value as soon as possible. Work begins and with effort we go live with what is the rough sketch of the application. It functions it even meets the the requirements, but it's a long way off the oil painting we originally envisaged.
The team start thinking about what areas of the sketch are most valuable as an oil pairing. Maybe we should do the head first?
But then, priorities change, and we shoot off in a different direction, leaving our hopes and aspirations of building a modern day masterpiece behind.
The next sprint, is working on an existing sketch, that's been adapted and morphed from man to woman.
Now we've decided we need an angry bird. It's quite a challenge, the body really isn't designed for this, it's to heavy, if we redesigned the body and made it lighter. We'd have to clean it up, certainly remove the remains of appendages previously removed. Then we could design some lightweight wings just simple enough to get us in the air and handle in an acceptable manner.
The estimates are larger, more than 1 release. Down to dealing with legacy code and getting into a shape where we can then add wings.
Could we simplify things to deliver value in the first release?
Well we could graft some wings on, it's not advisable, but we could do it, but we'd need to address the subsequent technical debt
and in the long term it's more expensive this way.
Do that, we make the release. At this point we have intential technical debt. The product does fly and we've leaned a lot about how we could best adapt the body to improve things.
Customers are happy it fly's but our angry bird handles like a pig.
Onto the next thing, in time we become surrounded by sketches and never any oil paintings. We're agile we're reacting to the demands of the Market, but are we ever meeting the needs of our Market.
We have a car and the customers want a plane, we can stick wings on the side of it and a propeller on the front. It fly's but it's not really a plane. Jet engines can come along, should we stick one in.
To rebuild a jet plane from scratch is to expensive, to break apart the legacy monolith into reusable pieces is also expensi ve. If we re-write and start again we could iterate quickly but will we still need a plane in 3 releases? Besides it's common knowledge that re-writing is the worst thing you can do
Starting a new sketch excites the team, we consider the possibilities and what it would look like when we get there, but will we ever get there. Many of the masters drew 100s of sketches, but it's their oil paintings we all remember.
Lots of companies made phones, but we remember the iPhone because it was revolutionary and started with a sketch, with some groundbreaking new ideas portrayed and the subsequently refined the work, adding 3G, cameras and a better screen.
When you consider, it wasn't launched that much later than Nokia's N95, it's a world of difference. Microsoft have recently released Windows Phone 7, which is a radical departure from the previous incarnation. It's behind, it may yet prove to be a failure, but I think they're in a much better position to run now than they were.
In conclusion, I think, being iterative and re-acting to the market is really important. But I think we need to take a sightly longer term view and keep iterating towards the vision we set out. We shouldn't be afraid of investing the time to firm up our foundations before standing upon them.