agile

I helped to organise a large (60+) Scrum Master community of practice.

Some of the lessons learned include:

Acceptance Criteria

Acceptance criteria are story specific requirements that must be met for the story to be completed. They are a technique for adding functional detail to user stories. Acceptance criteria are often added during backlog refinement or during the sprint planning meeting.

Some examples of acceptance criteria:

A Kanban board helps developers synchronise their work.

Favour a product approach over a project approach

Software development has traditionally been done in projects.

Wikipedia describes a project as:

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.

The first few steps in an agile transformation are critical to success. Lay a good foundation and what follows will be simplified.

So what is a good way to start an agile transformation?

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.

1. Mike Cohn - Mountain Goat Software

One of the founders of agile, Mike speaks with authority on a number of agile subjects. His focus is slightly more towards the product/project side with less focus on engineering practices.

Although not a hard-and-fast rule, I see the tiers of an agile organisation being the following:

1. Strategic tier
2. Product tier
3. Development tier

Strategic tier

The strategic tier is responsible for deciding the long-term goals, such as:

Even if I don't know how to implement something I can almost always write a test for it and If I can't figure out how to write a test for it I have no business programming it in the first place. - Kent Beck

Many processes in agile are mutually supporting. A good example of this is testing and its relationship to the development iteration.

Why would you want to spend time and effort to adopt agile?

That's a good question and one that should be asked and answered by your organisation before you attempt an agile transformation. First you need to define what you want to gain (or recognise a problem that you want to overcome). Then you need to agree how you will measure progress to ensure you are actually achieving what you set out to do.