This description of "the way we work" is targeted at new CloudCredoers, developers from other organisations that we pair with and other people which are interested in this process.
Every project stage starts with an Inception. Each project stage normally spans 3 months.
In an inception we talk about Goals, Non-goals, Risks, Actors, Activities and Stories.
The outcome of the Inception are pointed Stories the team can start working on straight away.
An Inception ends with a Retrospective.
Goals define the objectives for the current stage of the project. They are short-term, clear and with explicit value for the business.
The Non-goals are long-term project objectives which are out of scope for the current project stage.
Defining the Non-goals is important because the team needs to be clear about features that don't bring immediate value.
Risks are both expected and unexpected factors that can have a negative effect on the team's efficiency. Everyone involved in the project needs to be aware and try to mitigate them as best as possible.
Actors are type of users that perform Activities through which they will benefit from the features that the team implemented.
Stories are well scoped, small chunks of work that will be delivered individually and have intrinsic value.
Weekly meeting that marks the beginning of a Sprint. Everyone agrees on the difficulty of the Stories by assigning them points based on their expected complexity. The pointing takes into account the uncertainty related to implementing a story. This is a chance for everyone on the team to discuss and better understand individual stories.
The Product Manager - referred to as the PM - defines the priority of the stories after they get pointed. The end-goal is to focus on the most valuable stories for the business while taking the implementation cost into account.
Every working day starts with a Standup which gives team members the opportunity to talk about Helps & Interestings first, then summarise the previous day's progress. The team also decides if the pairs need to rotate.
The focus of a Standup is effective communication between team members - getting everyone in sync. Keeping it short and to the point is essential.
All stories get added to a Tracker Backlog. The team assigns them points at the beginning of every week, in the IPM. New stories can be added by the PM mid-sprint in exceptional circumstances.
Team members can add Chores to the same Tracker Backlog and choose to work on them at any point in time. This is one way of addressing technical debt or tackle issues which make the team less efficient.
Work will start with the top story in the Backlog - first in order of priority. Once the tests & code have been implemented for the story, committed to the central code repository and CI pipeline triggered, the story is marked as Finished. When the CI pipeline goes green - which implies that the CI artefact has been delivered - the story is marked as Delivered. The PM is now ready to run through the story's acceptance criteria and either:
- Accept the story which confirms that the implementation meets the requirements
- Reject the story with an explanation of the omissions or errors in the implementation
A story with business value.
A story which addresses a bug in a previously delivered feature - always linked to a feature story.
Allows developers to address technical debt or perform ad-hoc tasks which don't provide direct business value but are useful for maintaining team efficiency.
Work is always done in pairs. Reasoning about code, asking questions or challenging one another's thinking results in quick validation and better code quality. It is the most efficient way of sharing knowledge on the project. Working in pairs ensures that the code is immediately understood by more than one person.
The Retrospective is the last meeting in a weekly Sprint. Everyone is expected to talk about what they liked, didn't like or want to discuss freely with the whole team.
At the beginning of the Retrospective the team goes over the Action Items from the last Retrospective and marks the completed ones. Some items cannot be completed within one or even a couple retrospectives. That's fine as long as everyone keeps acting on them until they are completed.
Everyone is expected to write at least one item on the whiteboard in each of the three categories:
- :)
- :|
- :(
The outcome of a Retrospective are Action Items for next week which different members of the team take ownership of. Gettig them done will make things better for everyone.