Photo by ElbridgeGerryWe here at Nodeta work incrementally. We standardly split all of our development efforts into smaller and smaller increments in order to better grasp what is planned, what is achieved and how well the two match. We do small things to get big things done.
When you’re making a piece of software, the first version usually sucks. It doesn’t matter, if you whipped the software up in an afternoon, or if you spent thousands of man months to develop it from point Nothing to point Done, it’s gonna suck. Instead, you need to do it in small increments, and then you need to throw most of those increments away and do them again. The bigger the increment is, the more likely it is that it will be made of suck, and you’ll need to do it again.
You need to start with minimal features, then build. Test your ideas early with real users when possible and use that feedback to re-create.
In a personal sense, it’s not always so simple to adopt the concept of incrementality to your work process. Many would like to have their handiwork done, polished, framed and fixated before showing it to anyone.
Team members and incrementality
In Scrum, stories (which group smaller tasks in a single sprint) are given acceptance criteria, so that it’s easy to check how well the story has been completed or implemented. You can use these following criteria to either test your team or potential members for their abilities to work incrementally.
You, as a software developer, need to realize that your code is not valuable in itself, it is only valuable in what it can do, and if what it does is not useful that week, it has no value. No matter how long you pondered to find the best and most beautiful solution to the problem you had. Not even if your code flows down the misty meadows like a clear and concise natural language, if it is not a part of a proven feature, it’s worthless. You need to remove it and move on. Move to the next piece of code. You need to start feeling good about your ability to produce good code, and not about your code itself. Code proudly with the backspace!
You, as a manager, need to understand that your funky new features are worthless if the previous features haven’t been proven good by testing them with actual customers and actual users. Features have no inherent value. If you have a feature that reaks, you need to kill it fast and hop on the do-over train. You also need to appreciate the value of incremental development, and mold the day-to-day working environment to support it.
You, as a product owner, need to be able to plan well often and in variable scopes. Any project should have a road map, on what is sometimes called ‘epic level’. That means you take the contents of the project and try to define them in as broad as terms possible, without restricting development paths. Then you need to be able to chop these epic features up into pieces with the team, and prioritize, prioritize, prioritize.
Special feature
In software development, there are no manufacturing costs. That’s why do-overs are not only possible but smart. Incrementality is a special feature of software development, and one of the reasons why any comparisons to, say, construction development, lead to horrendous distortions of the truth. Think about it, if you could start building your house by simply setting up the planned facade and if you could then change it without material costs, wouldn’t you do it like that? Of course you would.
