Agile

Most of our customers are immediately attracted to the depth of our software engineering talent and our commitment to modern "Agile" development process. We have developed a strong reputation for completing complex projects on-time and on-budget.

Domain knowledge and technical expertise can not be fully harnessed unless it is matched with process instilment and disciplined project management. 3months is fully committed to using Agile methodologies to ensure that our clients get what they really want (which may not necessarily be what they think they want at the beginning of the project) for the right price. We are experts in the Scrum and Extreme Programming methodologies.

Agile methodologies are fundamentally different from traditional "waterfall" methodologies (where projects follow a discrete set of phases - analysis, design, built, test). Some of the difference Agile methodologies share:

Iterative Development

It is a well known fact that in software/website development the bigger the project the higher the risk and the more likely it is to fail. The simple solution - break it into smaller low-risk projects/phases/iterations. Each iteration is a self-contained mini-project composed of activities such as requirements analysis, design, programming and testing. The goal for the end of an iteration is a stable, integrated and tested partially complete system. The knowledge gained by the team in developing the iteration is fed into the detailed planning of subsequent iterations.

Many methodologies employ this strategy varying from phases lasting a few months (RUP) through to builds every day and tested iterations every two weeks (Extreme Programming). Every project is different and we will work with our clients to define the most appropriate development lifecycle.

Whichever methodology we employ and however big the project is, we believe that our clients must get business value (i.e. a released product/site) in under 3 months.

Adapting to Change

Do you know exactly what you want without ambiguity at the beginning of the project? Are you sure you will never want to change your mind during the project in response to changing business requirements or simply new ideas? If yes to the above, our experience is that you are in the minority and we would typically recommend a more traditional, non-agile, approach.

Agile approaches accept that requirements do change. Often people don't know what they want until they see it and therefore it is not practical or advisable to try to define all requirements and functionality at the beginning of the projects. In agile not all the requirements are gathered at the beginning of the project - agile embraces change and innovation through-out the project.

One Team

Problems in communication underlie most project difficulties. Traditional approaches promote the concept of the customer team communicating with the development team by means of large documents (requirements documentation, functional specifications etc). Agile approaches promote the idea of one project team made up of business and technical experts. If practical we work in the same room (we have purpose built project rooms if required) or we employ the latest technology (video conferencing, application sharing, web based shared project management/tracking software etc) to ensure optimal communication.

Managing Agile Projects

The best project managers aren't just organizers - they combine business vision, communication skills, soft management skills and technical savvy with the ability to plan, coordinate, and execute. In essence, they are not just managers - they are leaders. While this has always been the case, agile project management places a higher premium on the leadership skills than ever before.

For example, Agile project teams create and monitor their own iteration plans in collaboration with the customers. The customer creates stories (features) and prioritises them based on business value. The developers divide up the tasks themselves as they work and measures progress for each iteration (time-boxed development cycle), adjusting plans with the customer as necessary. So, if the project no longer needs a detailed master project plan, why does it need a project manager?

Because every project needs a leader. Agile methodologies free the project manager from the drudgery of being a taskmaster thereby enabling the project manager to focus on being a leader - someone who keeps the spotlight on the vision, who inspires the team, who promotes teamwork and collaboration, who champions the project and removes obstacles to progress. Rather than being an operational controller, the project manager can become an adaptive leader - if he/she can relinquish her reliance on old style management.

The basic phases of an agile development project are really no different from those of any other project. You still must define and initiate the project, plan for the project, execute the plan, and monitor and control the results. But, the manner in which these steps are accomplished are different and require the project manager to retrofit what they know about traditional management to a new way of thinking - the thinking of complex adaptive systems.

Keeping it Simple

Simple is good. The simplest solutions are when there is a suitable "off the shelf" product or software component that meets your needs. We can work with you to identify such a product/component (if one exists) and if necessary customise it.

For bespoke solutions we will always recommend the simplest possible route that meets your needs. The fewer lines of code we write the easier it is to maintain, enhance and change as your business changes.

Testing

In agile methodologies testing is "baked in" to the process from the beginning rather then undertaken as a discrete phase at the end. Automated unit tests are created during development allowing the entire site/application to be tested at the press of a button. Acceptance testing is undertaken at the end of each iteration (as opposed to the end of the project). By testing early we can identify problems/issues early and if necessary work with you to change direction before it is too late.

Honesty and Integrity

Agile work best when we trust each other. Trust is something that has to be built over time. Practices like iterative development and having one team communicating freely help to build this trust. We operate an "open book" policy whereby you have access to all our projects costs at any time.

Never dealt with us before and don't trust us? We would be happy to provide references.