Retrospective “mantras”

At the end of our last couple of retrospectives, we ended up with a set of actions that were really for the whole team to think about. Actually they were more like principles we should be following for the next iteration, rather than specific tasks.

Whilst retrospectives should really come out with very specific achievable and measurable actions, these more general themes can also be useful.

One of the team, Jeremy started writing the basics of the actions on cards as statements, like “Challenge Requirements”. We put these “mantras” on the wall and so we can see them and sometimes refer to them during standups.

This Iteration we did the same thing and it seemed to be a good way of capturing and making visible a result of our retrospective.

So far we have :

  • Challenge requirements
  • Understand Story Intention
  • Challenge the spike
  • Its not over until UAT (User acceptance testing or signoff)
  • Keep stories focused and SIMPLE
  • Migration code will ALWAYS be used again
  • Transfer ownership (of stories, if people leave or move teams)
  • Share Knowledge (as people roll off the project)
  • Is it releasable? (an individual story)
  • Demo Early

collective design

I gave a presentation at TW last thursday last month (August).

The subject was Collective design.

There was some interesting discussion about design in general.

For now, the slides can be seen here:

Collective design presentation

Software development implicitly creates a software “design”, the shape of the software artifact. To build software requires people. This talk discusses how the design of software is affected by and communicated between software developers, particularly on projects involving many people.


collective responsibility

How can you sit back and let people get on with things and yet have them deliver on time and in a coordinated fashion ?

I think a principal might be never to make guarantees on other peoples behalf. For example : you talk to someone and say yeah my guys can get that to you by next Thursday. This now means you have committed someone else to something they have not themselves agreed to. It might be more useful to have them talk to the party who wants something and then have them agree with that person to deliver said promise.

This relates to the idea of a team being responsible for deciding how much work they can do within an iteration. It is not one person but all involved who have committed to this amount of work. There is a group responsibility and this is much easier to run than the command and conquer approach.

Far from being unscalable to larger groups, you could argue that this level of decentralised drive is essential. However it is certainly possible for a single individual to provide the drive for many people , it tends to be quite autocratic though and can often make people feel threatened which is not an ideal environment for fostering creative work.


S.M.A.R.T.Y. Acceptance criteria

S – Smart
M – Measureable
A.- Acheivable
R – Relevant
T – Timed
Y – Why ?

The last one is interesting. I just found someone talking about it on the net. Its basically to help remember that a story should have a why ? Part.

AS someone I WOULD LIKE the system to do something for me SO THAT I can gain some benefit.

Acceptance criteria is the CONTRACT by which we agree with the client of the software we are writing what we will deliver.

Therefore it is the focal point of all parties involved. EVERYONE has an interest in what is contained therin:

THE CLIENT – This is how you make sure the team have understood what you want and how you MEASURE wether they have delivered it to you.

THE DEVELOPERS – this is how you make sure that you know the full extent of your work and thus how you know when you are finished with your job. Things outside the acceptance criteria which become apparent once you start a story must involve some kind of negotiation to append.
QAs – this is your lifeblood. It is impossible to determine if something is finished without knowing what its supposed to do. Acceptance criteria should be being consulted at every point in the develoment of a story. At the start, during and at the end. E.g. How many of the acceptance criteria have you met today ? This is what you will need to demo to the business.

BAs – you are the facilitator of the acceptance criteria. It is your job to negotiate between the ideals and desires of the client and the knowledge of the team of what is ACHEIVABLE within the given TIME PERIOD.

TEAM LEADs – these are what let’s you sleep at night. If there is well defined acceptance criteria the chances are that estimates will be more accurate and you will not have to explain why you have not delivered the functionality you guaranteed to the client.

Easy eh?