Blogs

Products versus Projects

 

Agile favours a product approach over a project approach

Software development has traditionally been done in projects.

Wikipedia describes a project like this:

In contemporary business and science, a project is an individual or collaborative enterprise, possibly involving research or design, that is carefully planned, usually by a project team, to achieve a particular aim.

Great agile quotes

 

Three bloody roles, Scrum has, and only three. If you can’t get that right, don’t call it Scrum, OK?

- Ron Jeffries

 

When we are blind to systemic causes of problems, all the solutions we try will likely make matters worse.

- Esther Derby

 

If we have a fully defined backlog, we no longer have a true Agile Product Development situation. Instead, we have a project

Scrum myths

 

The following are some common Scrum myths.

 

Velocity is a measure of performance

Isn't a higher velocity a sign of a more productive team?

The Scrum guide is very clear that velocity is purely about establishing the likely capacity of a team for future sprints. The actual value is irrelevant, it is the predictability that is important.

 

8 golden rules of a development team

Golden rules of a development team, compiled from personal experience and from a number of books, academic papers and other sources.

1. Use the same deployment mechanism for all environments

When you do something often, you get good at it. So deploy to all environments using the same mechanism. That way, when you deploy to production things less likely to go wrong.

 

Lessons in agile communication

Agile emphasises the importance of communication. This is not just about the formal communication at stand-ups and meetings, it is also about everyday communication within the team.

Consider the following example.

A team member tries something new with some automated tests. They hope the change could be an improvement and that it could provide significant benefits.

Sustainable Pace

It has long been a tradition in waterfall style projects to associate long hours with increased productivity. A recurring pattern is up-front planning, followed by realisation that a deadline is not going to be achieved and then finally a push to increase working hours.

Performance Benchmarking

Performance testing is often difficult and expensive to do. When you need to get real-World performance figures you need to test on real-World hardware and this is not always possible. Even when it can be achieved it is difficult to do frequently without a dedciated (and hence expensive) performance environment.