Implementing an agile approach – steps towards agility

By | 29/01/2017

The term agile has become a popular term and approach for delivering solutions.  It is an alternative to the traditional waterfall approach.  Its key focus has been to deliver faster, greater collaboration between stakeholders and more adaptable at incorporating changes.  It does this by breaking the work down, prioritising items of highest value and getting output in front of the customer quickly in a set period so it can be reviewed and changed if necessary.   It involves stakeholders such as the customer, developer and tester working closely together to produce the output.  It may be necessary to choose a pilot picking a project which has criterion of high priority and strict deadlines.

See diagram below for the considerations required of what is required to adapt an agile approach.  The diagram breaks the main components into 4 categories.

These are:

  • Cultural
  • Governance
  • Project level
  • Process

Cultural

An agile approach means greater collaboration and frequent communication across what would normally be from people in different teams who would normally be involved at different times and work in different ways.  A cultural change is required to bring these people together and collaborate as one team.  An agile approach is normally more resource intensive requiring a clear commitment to the project.  The timescales may be shorter but there is greater engagement required.

Governance

If a traditional waterfall approach is normally used, then there may be strict staged gates that need to be signed off before moving to the next stage.  So typically for waterfall this may mean requirements being signed off before design, design before development etc.  As agile involves doing these stages in parallel there could be a conflict.  There must be an agreement as to how governance will work considering the differences with agile.

The same applies to documentation standards.  Heavy textual documentation isn’t going to suit the approach required.  User stories and diagrams are normally favoured instead as can be produced to convey the same messages faster.

Governance around decision making also needs to be addressed.  The customer involved in the team needs to be empowered to make the decisions and be self organising.

Release planning is also a consideration to allow iterations.

Training and coaching in agile is required to understand the philosophy and what tasks are required and why.

Project level

The project itself should meet certain criteria.  Questions to be asked are the following:

  • Can it be split out into definable deliverables and in an iterative way, can it be prototyped or working software produced quickly and in an iterative way?
  • Are timescales important? This is one of the benefits of an agile approach because the emphasis is working out what can be done in a set period.
  • Are the requirements unstable or lots of unknowns? This will benefit an agile approach due to its ability to produce tangible outputs quickly and respond to change.
  • Are all the required team members available, committed to the time they are required and involved early on?

Process

Preparation and planning is required to agree the logistics and what is to be covered within each iteration.  It is also important for re-planning as more is understood about the solution requirements, progress and priority.

The following meetings need to be planned and will vary in frequency and duration:

  • Initial planning meetings to agree how many iterations are required and what to include in them – typical duration of a week
  • Re-planning meetings to adjust priorities if required – typically fortnightly
  • Daily stand ups – typically lasting no more than 15 minutes
  • Retrospective meetings to review progress – typically 4 weeks at the end of an iteration
  • Demo meetings to show the progress through working software or prototype to validate the requirements – typically 4 weeks at the end of an iteration

Use cases / user stories and features must be defined and a process for organising the requirements as they are progressed and built on.  Even though documentation is normally more light weight it is still important to maintain something that can be used by the other team members and to enable a view of how they are fitting in with the plan and progress.

Other articles written which include agile are:

 

Thoughts? Questions? Please share in the comments.

Author: Helen Winter

An Management Consultant responsible for structuring programmes, success criteria, mobilisation, management of scope, budget, timely delivery, benefits realisation and stakeholder satisfaction. Helen has led on large transformation programmes to execute delivery along with strategic business outcomes. Helen is also a global business author with publisher Kogan Page where her first book “The Business Analysis Handbook” was a finalist for 2 major industry awards. One was for contribution to project management literature with PMI and the other was the Specialist book category for the business books awards. She is an active member of the APM programme management group. She is currently involved in a focus group sharing examples of good programme management practice and is an established speaker for project management forums. In her free time, she loves sharing her knowledge on her blog BusinessBullet.co.uk which is followed by over 5000 visitors a month.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.