Agile project teams focus on quickly providing valuable product features to the customer, and to provide frequent updates as a result of engaging with the customer to validate their needs. Alternatively, it can be about the throughput of valuable change for non-software related tasks.

Getting frequent feedback from various user groups is often a task that is planned by agile teams.

Embrace change on projects. Even late in development. Change helps to ensure that the customer gets exactly what they need, as well as gaining an advantage over competitors.

Agile practitioners prioritise high value features and functions, but we all know that the priorities can change as new business challenges are uncovered.

Delivering frequently is consistent with the customer focus philosophy, whether it be the delivery of software functionality or other improvements to the organisation and processes. These iterations are done in 'sprints' of 30 days or less and helps the project team focus on achievable pieces of work.

Quicker delivery also provides the chance to get feedback, helping to determine whether the project team are following the right path, and if not, to reprioritise and add change.

The business understand the market and it's customers, and therefore which features / steps are needed to meet their expectation.

They should be the ones who decide the product features and be the Product Owner, assisting the Scrum Master in directing the tasks for each sprint.

Unlike the traditional way of development, their input is not just needed at the beginning, but throughout the project continually feeding their requirements for new features, in a  just-in-time fashion.

They should be easily accessible, and available to work closely with the developers.

This is about utilising people who love what they do and are passionate about doing it.

It's also about giving team members the support they need to complete their tasks. A good Scrum Master will seek to remove the blockers that team come up against.

Finally, Agile practioners trust the team to get the job done. Monitoring isn't done with the aim of spotting weak performers; it's about identifying what the team needs in order to thrive.

Face-to-face communication is the most effective method for exchanging ideas and agile teams try to maximise this.

Ideally the team should be located together, although they are usually separated. Conference or video calls can bring the team closer.

When it comes to documentation, it's about having just the right level. If something is simple, it probably doesn't need to be documented. But as complexity grows, or information needs to be tracked, it may be necessary to document certain features.

Working software is that which is successfully tested and delivered.

Ideally there will be acceptance criteria to define what 'working' means, and a test set should be ready to test against.

If software really is being delivered frequently, the testing burden may become heavy due to regression and no impact testing.

How do we measure progress?

The tricky part is defining the right metric, but once chosen, monitoring of progress will be possible and teams will find it in themselves to be more effective in future iterations of work.

The aim is for agile team members to achieve a good work-life balance and to avoid burnout due unresponsive planning.

How many projects have you had to work long nights and weekends due an unrealistic plan that was originally set? Whether it's waterfall or agile, I think this principle is the one that is seen as only being an aspiration.

If all the team does is tackle each task without regards for technical excellence, the result will be an assortment of functions which work, but may not represent technical excellence.

This could eventually lead to the situation where much re-work needs to be done for each small change.

Focus on those parts that get the most results. The 80/20 Pareto rule states that 80% of your performance only comes from 20% of the effort

The basic principle is that the team is responsible so let the team naturally evolve into its expert areas.

It is okay to make mistakes, as long as these are reflected upon later.

Team reflection is where the team can look back at the most recent sprint and identify areas that can be improved to enhance the next sprint.

Have stand-ups evolved into sit-downs? What has caused this? Are stand-ups taking far too long? What can be done to improve this?