An Agile Approach to Project Delivery

An Agile Approach to Project Delivery

How can Bridgeall ensure that the ideas you have for a new IT development are understood and implemented, while delivering on time to budget?

It’s already been well documented that IT projects can and do often go horribly wrong, particularly when the initial systems specification isn’t written in concrete. My own experiences of being responsible for implementing new systems in a traditional, waterfall style have been fraught with setbacks. Essentially, projects suffered badly when client specifications were loosely defined and costs spiralled.

Enter Agile.  Nowadays everyone says “we’re agile” but what does it mean, what actions should I take and more importantly how will that benefit you, our prospective customer.

Fundamentally I believe that being Agile means delivering business value frequently and consistently while adapting to changing business needs.

Translating this statement into action, this means that when my company Bridgeall delivers an agile project, we focus on four fundamental drivers:

  • Focus on return on investment from an early stage. With our customers engaged we prioritise those user stories that are known, or can be known quickly, and represent highest value for the customers.
  • Deliver working software early and often. Undertaking the practices of Test Driven Development (TDD) and Continuous Integration (CI) supported by a top-end development environment enables Bridgeall to deliver production quality code on a regular basis. Iteration lengths and release frequency are agreed upfront with our customers.
  • Value customer collaboration over contract negotiation. Obviously contracts are important to Bridgeall and our customers also but long term relationships are built by communicating clearly and often with our customers so as to clarify requirements, plan effectively and address risks. We seek customers who want the same approach since distant or adversarial relationships are not what we do.
  • Respond to change over following a plan. One surety we have observed is that the scope of a project at start-up is never the same at closedown. To deal with that effectively we agree wholeheartedly with General Dwight D. Eisenhower, 34th President of the United States (1953-61) who stated that “In preparing for battle, I have always found that plans are useless, but planning is indispensable.” Our planning process means that we are prepared and ready to react as change occurs.

We adopt a Test Driven Development (TDD) approach centred on automated testing and once source code is checked-in it undergoes immediate unit testing as part of our continuous integration (CI) builds. Full system test builds that include all UI tests are triggered automatically if all unit tests pass. This avoids last minute and expensive bug fixing at a time when you should be going live.

TDD is an evolutionary approach to development which combines test-first development where you write a test before you write just enough production code to fulfil that test and refactoring. TDD, when carried out properly and with rigour, results in higher quality software. In test-driven development, each new feature begins with writing a test. To write a test, the developer must clearly understand the feature’s specification and requirements. The developer can accomplish this through use cases, user stories and screen mock-ups that cover the requirements and exception conditions.

This is a differentiating feature of TDD versus writing unit tests after the code is written: it makes the developer focus on the requirements before writing the code, a subtle but important difference. Any code checked in must adhere to our check-in policy before it will be accepted by Team Foundation Server (TFS) source control.

CI is a software development practice that requires team members to integrate their work frequently. Every person integrates at least daily, which leads to multiple integrations each day. Integrations are verified by an automated build that runs regression tests to detect integration errors as quickly as possible. We find that this approach leads to significantly fewer integration problems and enables development of cohesive software more rapidly.

To manage our Systems Development process we use Visual Studio ALM (formerly branded as Visual Studio Team System) for all development projects. ALM is a top-end environment for professional application development and Bridgeall has used this since 2006 for all development projects.

Team Foundation Server (TFS) is the collaboration platform at the core of the Visual Studio ALM providing fundamental services such as version control, work item and bug tracking, build automation, and a data warehouse.

With our agile approach to development our customers benefit from incremental and regular releases of high quality features that match their requirements. Our close and regular communication avoids unwelcome surprises and sustains long term and effective relationships.