I’d like to say that there are two big things we must achieve in software development. We must build the right thing and we must build the thing right.
Building the right thing starts with what the customer wants so they can gain value from our work.
The way we build the right thing for the customer in Agile software development is with frequent feedback. We build a little and then we take it to the customer and ask, “Is this what you want?” And we listen.
Software development is a discovery process for the developer as well as for the customer, and by partnering with the customer and discovering together the best way to achieve their goals we can build a better product. This is really the essence of Scrum and why having a short iteration cycle is so valuable for building the right thing. People can’t always come up with solutions to problems but they can recognize that they have a problem and when the solution is presented they can see that it will help. With constant feedback most teams get to build something of value to the customer.
When we order our backlog then the things that aren’t as important just drop off and we’re focused more on the things that provide the highest value to the customer. An ordered backlog is not really to help us build the most important things first, as much as it is to help us not build the least important things.
In Waterfall, customers know they get one bite of the apple and so everything becomes critically important. But with the ability to give constant feedback, customers can be more focused and identify the next most important thing that gives them more information about what is and what isn’t important for future iterations.
If we don’t build the right thing then all bets are off because no matter how beautiful our code is the customer will not find value in it. But just building the right thing is not enough either, we have to build the thing right.
Something that is often overlooked is that Agile and Scrum are more than development processes, they’re ways of building software. To do Agile successfully doesn’t just mean having standup meetings and doing sprints, there’s a lot more to it.
Building software right means understanding what good software is and how to create it.
Unlike other engineering disciplines, which are true disciplines, software development is often fly by the seat of your pants, make it up as you go along, clump something together that seems to work, and hope for the best.
You can’t just hang a shingle outside your door and say you’re a doctor, it’s illegal. But you can hang a shingle out your door and say you’re a programmer. There is no standard body of knowledge that’s recognized as prerequisites for becoming a software developer like there is in medicine or the law.
As such, it’s not easy evaluating a programmer’s capabilities. We’re not a homogeneous group. If teams do possess a set of general standards they often go unspoken so it’s typical to see huge differences between coding styles among developers in the same team. This promotes individual code ownership rather than collective code ownership and keeps knowledge of a system from disseminating to all team members. When we silo knowledge and foster specialization, projects suffer and teams become dependent on specific individuals to maintain aspects of the system.
Building the thing right means employing good engineering practices and elevating software development to a true engineering discipline. This means that developers must have a core set of knowledge and common goals: the sort of principles and practices I cover in detail in Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software.
This doesn’t necessarily mean that software development becomes rote. Every problem needs unique solutions but we can find common ways of approaching problems that give us traction and we can build our common vocabulary. That gives us the ability to communicate better among ourselves, gives us a better ability communicate what a program does.
Building software is among the most complex activities humans can engage in. We need guidelines to help us and that really is what the Agile software development movement is bringing to the table.
Previous Post: « Success to Standish is Failure in Agile
Next Post: The Importance of Technical Practices »