I am doing a presentation on The Kanban Method for Software Development for the Jo’burg Centre for Software Engineering’s (JCSE) Agile Forum in the coming month. In preparation, I’m blogging on some of the ideas I’ll be presenting. I’ll start off with some concepts I like to think of as truths of software development. The first truth is concerned with the answer to the question ‘what is the goal of a software development team?’
One of the first questions I ask colleagues and clients when talking about improving a software development organisation is ‘what is the goal of a software development team?’ It may be obvious that my thinking around this question is heavily influenced by Goldratt’s The Goal and Theory of Constraints. For me, this is the most important question (and answer) one can ask when trying to improve, for various reasons. The first being that unless one knows what one’s goals are, one is lost, there is no direction and no way to measure progress. The second, is that in software development specifically, I believe the goal is so misunderstood that people implement silly and needless processes which actually prevent them from achieving what they should be. Think about how you would answer it before continuing.
The goal of a software development team is to deliver software. Not to develop, test or specify software, but to deliver it. Of course we need to add some qualifiers, such as ‘at the right time, of the appropriate quality’ etc. The fundamental reason for this is that one can’t generate revenue or a return on investment except through working software. Another reason is that without some form of working software, it can be exceedingly difficult to refine a customer’s vision for a product, or get customer feedback about the product. The easiest analogy in this case is ordering a pizza. There is no value delivered by the pizza maker until the pizza is delivered to the customer.
This concept of the goal being delivery of software resonates with the statement in the Agile Manifesto that we value working software over comprehensive documentation. I would go so far as to say that without working software, any other artefacts are without value. How many people have made money selling functional specifications, technical documentation or test plans?
The most important thing for our customers is a solution to their problems, and for teams involved in software development, this takes the form of working software. The quicker this software can be delivered, the better, from the customer’s point of view. Thus any framework for software development must optimise for delivery: the quicker we can get this stuff out the door, the better.
I harp on this point, because I believe introduce many sub-optimisations, and introduce many obstacles to delivering working software because they misunderstand this. I won’t go into too much detail here, but things like siloed management, big upfront processes, and certain types of non-instant-availability constraints all detract from delivering software, and all are introduced with the best of intentions.
Do you agree? Do you have other (primary) goals for your software development team?
Func(Of Inspiration) - Joshua Lewis's Blog 