Agile strategy and development
Jinfo Blog

By Sarah Dillingham

Abstract

In the bad old days, IT would go out to the business, write down a big list of requirements, build a shiny new product and unveil it to the business three months later with a big “Ta Da!”. Sadly, too often the outcome would be a product that fitted the initial brief, but didn’t hit the needs of the business. Thankfully we’ve moved on since then, and "agile" offers a set of methodologies used by many development teams. It is particularly prevalent in relation to collaboration tools e.g. websites, SharePoint and social media.

Item

Knowledge managers love to remind our clients and customers that technology is merely one part of good KM. Empowering people to collaborate and embedding business processes to unblock barriers to sharing are equally important.

But technology is an essential cornerstone of good KM, whether you are improving existing systems and architecture, looking to create a new bespoke system or buying off-the-shelf.

Whether you are working with an in-house team or hiring an external agency, it is valuable to understand how your developers work. This will enable you to manage your project timelines and stakeholder expectations better.

In the bad old days, IT would go out to the business, write down a big list of requirements, build a shiny new product and unveil it to the business three months later with a big “Ta Da!”. Sadly, too often the outcome would be a product that fitted the initial brief, but didn’t hit the needs of the business.

Thankfully we’ve moved on since then, and "agile" offers a set of methodologies used by many development teams including large organisations such as British Airways. It is particularly prevalent in relation to collaboration tools e.g. websites, SharePoint and social media.

The first principle of agile software development is “to satisfy the customer through early and continuous delivery of valuable software”.

One popular agile methodology is Scrum. This involves developers working for a set consistent period of time (or “sprint”) on a project. The work carried out in each sprint builds iteratively upon the last piece according to feedback from the business stakeholders in liaison with the development team.

The approach works because the business and the development team have a high level of contact. There are multiple opportunities to review progress at the end of sprints and make the required iterative changes.

If there are changing business priorities during the course of the project, they can be incorporated into the build. The final product will evolve from this process and, as a result, will be closer to meeting business needs.

Like any methodology there are disadvantages. The business stakeholder representing the needs of the business must be keyed in to the right decision-makers, and truly understand what their business is trying to achieve with the project in order to communicate effectively with the development team. They also need to have enough gravitas not to be swayed by every piece of individual user feedback, but rather to judge when changes are appropriate.

To find out more about agile development and the terminology associated with it, take a look at these guides:

• Principles behind the Agile manifesto
• How British Airways uses Agile
• Benefits and challenges of Agile development – from CIO.com
• Scrum Methodology
• Agile 101 – agile methodologies

« Blog