How much time should be spent on a project before starting with development? It can be safely said that this is one of the most talked about topics when people in the software industry come together. There (still) are some who think that everything can be designed before a single line of code is written. But many industry veterans would now go into the other direction and advocate successful communication between developers and the end user throughout the duration of the project as the single most important factor for project success.
Project success can mean many things. For us it means that the developed software is useful to the end user. Useful means that the software actually improves the process the end user is using it for. This can often be quantified by measuring the time saved when using the software to the state of affairs before. We do live in a world of finite resources, therefore on time and cost delivery of a project obviously should not be underestimate. But keep in mind that on time and or cost delivery only does not mean it is actually useful to the end user.
Reality is that every so called development methodology (just a fancy word for method) is pushed by someone in the industry with vested interests. There are the multi-billion dollar companies that offer an extensive and expensive range of integrated software development tools that will tell you that efficient software design can only be done with their brand of tools and a formalised design language. And then there are all the methodology gurus and software consultancies that are charging their clients by the hour and the more upfront design they can sell their clients, the more money they will make. Reality is that many managers feel more comfortable with early upfront design because it creates huge amounts of documentation (nobody reads) and that creates the illusion of a more manageable project.
On the other hand there are the agile development methodologies that put communication between the developer and the end user above everything else (Agile Manifesto) . Communication starts with writing down requirements together in plain mother tongue. A good requirement is small, testable, valuable to the end user and should be independent from other requirements. It is followed by iterative development step that produces running software at the end of each iteration. That is when the developers and the end users come together again and go through the available software and find out what needs to be changed, extended or dropped. Over several iterations they, at least most of the time (or so it is said), end up with software that the end user is happy with. The proponents of agile methodologies claim that changes to the requirements throughout the lifetime of the project are an integral part of the method because nobody can foresee every single requirement (see post about requirements gathering). Some only become apparent during development.
So who pushes agile development? Agile development is pushed by small software houses because it creates a competitive advantage over large slow moving competitors with their armies of formally trained software developers. Small companies are so much more adaptable and are more willing to integrate change into their idea of project management and agile really highlights those strengths. Not to underestimate is the amount of money saved when not using the expensive design tools and training the developers to use them. Because agile is quite a loose approach, there are many different agile methods. Even though they fundamentally are the same, some still claim “moral” higher ground for their agile cult. Things never change.
As you can easily see from the above post, Outfarm is using an agile approach to software development even though we are working with an outsourced development provider. This goes against the “throw it over the wall and see what comes back” mentality of outsourcing which has very little chance of succeeding anyway. We are not advocating against using formalised approaches, but we choose an agile approach because:
- We worked with formalised approaches and didn’t like it
- We can’t afford spending 6 months in a design phase and prefer to talk to each other about requirements
- We are impatient and want to be able to see/touch/feel the software as it develops.
- We are the end users and know that we will introduce more requirements along the way.
- We see our developers abroad as peers, not as code monkeys
- Ongoing communication with the developers gives us greater control over the project because we get a better understanding whether they understand the requirements and because we love their crazy accents
- We have limited resources and believe that an agile approach will get us there cheaper and faster