Why we are choosing agile development over a more formalized approach 30 Jun 09

0 Comments »

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

Choosing a supplier: Other considerations (Part III) 10 Jun 09

0 Comments »

Does your project management process match?
The best way to find out how a supplier actually manages a software project is with the STAR method. Simply asking do you use an “Agile approach” will in most cases be answered with a yes and is then often followed by a frantic search for documentation if in fact it wasn’t used before. Some processes are simply not compatible and trying to combine them will end in frustration for both sides. Try to combine an agile process with the CMM Level 5 certification. The other extreme is the supplier companies that rely on the process of the client; just think about how long it took the get the process to stick in your own company (if you are actually using a process). In the absence of a shared process or a process in general, many suppliers simply revert to the waterfall model which should never be used! In our case we looked for a company that followed the agile development approach close enough to match our own process.

Consider a small project first
If you can afford it, go with a small project first. Smaller projects, even if they are only one to two weeks in duration, will give you a very good understandig whether you and the supplier can work together. Define milestones, deliverables and acceptance criteria close enough to how you would do it in the larger project.

Don’t be dazzled by software development language
If you have ever dipped your toe into software development, you were, most likely, initially thrown back by the sheer amount of abbreviations and hype words that are used in this industry. The basic rule here is to play dumb and ask everyone to explain it in clear English to you (or your mother tongue if at all possible). The truth is that many people working in that area love to hide behind those big words. The rule here is clear, if someone can’t explain a concept to you in words you understand, then that person probably doesn’t understand it himself and has no business behaving as if. As matter of fact the STAR method is great at exposing someone just talking the talk.